Reading CHGCAR and POTCAR directly

[ondrejkrejci]

@mondracek found out that not every CAR -> xsf converter follow the xsf rules, thus to ommit problems it would be good, to go directly from vasp output.

an idea could be here: https://pyscf.org/_modules/pyscf/tools/chgcar.html

[mondracek]

Specifically, the problematic tool is VASPKIT. Currently, the ppafm code simply fails with *.xsf files obtained from CHGCAR or LOCPOT using vaspkit as the converter. The failure could be prevented by a trivial modification of the loadXSF function in io.py, one that would allow the grid data section to begin with DATAGRID_3D rather than BEGIN_DATAGRID_3D. However, then a more subtle problem would appear, related to the discussion about extra points on the the grid boundary in XSF format. It is actually the same issue that I have reported for our OutFz.xsf files as #337. I have verified that the resulting CHGCAR.xsf files from vaspkit are slightly wrong when visualized by either xcrysden --xsf or vesta in that the maxima of electron density do not exactly align with atom (just as the force maxima do not align with chlorine atoms in my example).

As I am already writing my own loadXSF and saveXSF functions, I can write ones for reading the CHGCAR and LOCPOT files too. I am not using objects/classes in what I am doing. We may later want to switch our code to an object-oriented style. Once we are doing it, my plan is either to rewrite those functions again (while keeping the content of the code as much as possible and changing only the syntax) or use some external tools like those linked by @ondrejkrejci , which I think typically do use objects (in the sense of class instances) to pass their results.