Dear Saulius,
On Tue, Jul 22, 2014 at 9:29 AM, Saulius Gražulis grazulis@ibt.lt wrote:
Dear TCODers!
sorry for a period of silence. It took me a while to digest all ideas expressed on this list, catch up with the work done by other groups (Quichote, CompChem).
I am toying with the idea that TCOD should have 3 levels of structure description:
-- level 0:
- cell constants;
- atomic coordinates;
- literature reference.
I think, it is in general a good idea to have levels in TCOD! Having the the most important parameters and the correct reference to the literature is probably enough to decide on whether the data entry is of any use or not. However, it will not be enough for properly checking/reproducing the cited result.
Standard CIF dictionaries are enough for such description.
-- level 1:
- same as in level 0, plus any parameters that permit qualified person
to judge if the structure has converged and how good it is. The parameters should include residual force on atoms (2014-02-10 16:16, Björkman Torbjörn), energy change(s) in the last cycle(s), and references to basis set, pseudo-potentials, XC functionals, etc. (as described in our dictionaries and in http://www.xml-cml.org/dictionary/compchem/). Basis sets can be referenced as in https://bse.pnl.gov/bse/portal;
That's great. Having the most relevant parameters would be enough to try to reproduce the result.
I still hold to the statement that it's is almost impossible to reproduce the exact results using two different codes even though the settings (xc functional, basis, pseudopotential, k-point sampling etc.) are the same. The numerical implementations could be significantly different and there are always a bunch of hard-coded parameters which are different for different implementations.
I don't think it is so important to have the energy convergence reported. It's a crystal structural database, so the it is probably enough to report 8 things from the last step:
Max Force on Atoms RMS Force on Atoms Max Displacement on Atoms RMS Displacement on Atoms
If the cell optimization is performed:
Max Force on Cell RMS Force on Cell Max Displacement on Cell RMS Displacement on Cell
-- level 2:
same as in level 1, plus:
copies of all input files (such as .inp files), or stable references
to them (possible in case of widely used basis sets or pseudo-potentials); the text of these files could be stored, unparsed, in appropriate CIF data items so that one can extract those files and run the code automatically;
command line used to run the code;
optionally, output logs of the run;
the name, URL reference, and version of the program used for
computations;
- for F/LOSS programs and systems, we can store the source code and the
packages -- these can be re-run on emulators when the code and the systems become obsolete.
As I said, this could be extremely tricky. Don't think it makes much sense to store the output logs, since they can get huge. What we could do, is to define a couple (3-5) of "Reference codes" which could be supported for checking/benchmarking purposes. VASP, QuantumEspresso, GPAW? Which inputs we could store and structures submitted from other codes should stick to those benchmarks. As far as I know some of the databases use in their philosophy (e.g. they would only accept VASP results calculated using some minimum criteria). In this way one can be consistent.
Rationale for the level 0: at the moment, all TCOD CIFs are of this kind, so we are just expressing the state of the art. This assumes that referees and editors were careful enough to review the paper, check the convergence, that nobody has confused the coordinates, etc.
Rationale for the level 1: we need some criteria to select structures for further processing, review, etc. We will start with the minimal set of tags (data names), and add more when necessary.
Rationale for the level 2: in the nearest time, the computations can be re-run from such representation, and modified computations can be done. In the more distant future, the codes will become obsolete as Stefaan correctly predicts in his 2013-08-19 18:30 e-mail, but we can still read, analyse and parse the logs, and possibly extract more information that was parsed during the deposition.
Copying and dumping all inputs and outputs captures all relevant information, allows to re-parse it in the future if necessary and accommodates any new codes and new developments of old codes.
People who are not willing to share their scripts can stick to level 1 as long as their publishers, funders and community do not insist on level 2 :). TCOD as a database is neutral about this (although TCOD maintainers or participants can have their strong opinions on the subject ;)
Large intermediate or derivable files (electron/spin density maps, wave functions) will not be stored at the moment, and if they will, they will be added as separate files.
What you think about such policy?
Great job, Saulius!
Regards, Saulius
PS. In a while, I'll send you a version of our poster for IUCr for the review, and some updates to the COD dictionaries.
Best regards,
Linas
-- Dr. Saulius Gražulis Vilnius University Institute of Biotechnology, Graiciuno 8 LT-02241 Vilnius, Lietuva (Lithuania) fax: (+370-5)-2602116 / phone (office): (+370-5)-2602556 mobile: (+370-684)-49802, (+370-614)-36366
Tcod mailing list Tcod@lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod