[TCOD] TCOD dictionaries and data presentation -- 3 levels of description

Linas Vilciauskas linas.vilciauskas at nyu.edu
Fri Jul 25 03:29:43 UTC 2014


Dear Saulius,


On Tue, Jul 22, 2014 at 9:29 AM, Saulius Gražulis <grazulis at 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 at 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 at nyu.edu
Phone:  +1-347-614-6831
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crystallography.net/pipermail/tcod/attachments/20140724/6fd091c3/attachment.html>


More information about the Tcod mailing list