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



--
Linas Vilciauskas
Postdoctoral Research Fellow
Dept. of Chemistry
New York University
100 Washington Square East / 830BB
New York, NY 10003
linas.vilciauskas@nyu.edu
Phone:  +1-347-614-6831