Dear all,

Running to keep up with the discussions here... Anyway, I have started to further develop vasp2cif to also extract all the relevant DFT parameters from VASP output and Saulius is going on something similar for abinit. This made some problems apparent.

Stefaan Cottenier:

Specifying the XC-functional limits us to DFT only. Perhaps the keyword should rather be 'level-of-theory'. If a LIBXC-identifier is given, then this implies it is DFT with the quoted functional. If the value is not a LIBXC-identifier, it refers to a non-DFT method (Hartree-Fock, GW, QMC,...) It might be tricky to create a relevant list of non-DFT methods, and right now it is perhaps of limited use, but the number of predictions by these methods is likely going to surge in coming years.

I think that one puts the _tcod_model to 'DFT' here to signal that it is DFT.

I like the idea of using LibXC identifiers, that way we can help the only standard naming scheme slowly solidifying. The problem with LibXC is that they only name what they have implemented, and this covers only a small portion of all the possible methods (although a very large portion indeed of the methods actually used...) For example, one of my favourite classes of methods right now, non-local correlation van der Waals functionals, are not included in LibXC and thus has no naming scheme. For that reason, I would prefer to leave the functional as a "free" string, but try to primarily use the LibXC names whenever possible.

I also realize that we may need tags for (semi-)empirical dispersion force parameters, particularly the Grimme scheme which is very popular. I guess that those would be introduced on a form similar to the U and J parameters now, something like: data_dft_atom_type_grimme_C6 data_dft_atom_type_grimme_radius

Concerning the number of dimensions we allow.... as someone currently working with low-dimensional crystals (2D to be precise), I am reluctant to throw these out. They are perfectly fine crystallographic objects, I think, at least I seem to spend any amount of time looking at their electron diffraction patterns... From a technical standpoint they cause not real problems, you just give the size of the simulation box. I remember putting in tags to mark up whether periodic boundary conditions were used, since there are codes that can cut these along one direction, but these still typically use a finite size simulation box (as Stefaan says, there are exceptions, but not many). The CIF format of course also requires this box size to be expressed as a lattice vector, but this is not really a problematic point, this just reflects what people mostly do anyway.

Cheers, Torbjörn

--- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland