<div dir="ltr"><div class="gmail_extra">Dear Saulius,</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 9:29 AM, Saulius Gražulis <span dir="ltr"><<a href="mailto:grazulis@ibt.lt" target="_blank">grazulis@ibt.lt</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear TCODers!<br>
<br>
sorry for a period of silence. It took me a while to digest all ideas<br>
expressed on this list, catch up with the work done by other groups<br>
(Quichote, CompChem).<br>
<br>
I am toying with the idea that TCOD should have 3 levels of structure<br>
description: </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-- level 0:<br>
- cell constants;<br>
- atomic coordinates;<br>
- literature reference.<br></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Standard CIF dictionaries are enough for such description.<br>
<br>
-- level 1:<br>
- same as in level 0, plus any parameters that permit qualified person<br>
to judge if the structure has converged and how good it is. The<br>
parameters should include residual force on atoms (2014-02-10 16:16,<br>
Björkman Torbjörn), energy change(s) in the last cycle(s), and<br>
references to basis set, pseudo-potentials, XC functionals, etc. (as<br>
described in our dictionaries and in<br>
<a href="http://www.xml-cml.org/dictionary/compchem/" target="_blank">http://www.xml-cml.org/dictionary/compchem/</a>). Basis sets can be<br>
referenced as in <a href="https://bse.pnl.gov/bse/portal" target="_blank">https://bse.pnl.gov/bse/portal</a>;<br></blockquote><div><br></div><div>That's great. Having the most relevant parameters would be enough to try to reproduce the result.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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:</div><div><br></div>
<div>Max Force on Atoms</div><div>RMS Force on Atoms</div><div>Max Displacement on Atoms</div><div>RMS Displacement on Atoms</div><div><br></div><div>If the cell optimization is performed:</div><div><br></div><div>Max Force on Cell</div>
<div>RMS Force on Cell</div><div>Max Displacement on Cell</div><div>RMS Displacement on Cell</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-- level 2:<br>
- same as in level 1, plus:<br>
<br>
- copies of all input files (such as .inp files), or stable references<br>
to them (possible in case of widely used basis sets or<br>
pseudo-potentials); the text of these files could be stored, unparsed,<br>
in appropriate CIF data items so that one can extract those files and<br>
run the code automatically;<br>
<br>
- command line used to run the code;<br>
<br>
- optionally, output logs of the run;<br>
<br>
- the name, URL reference, and version of the program used for<br>
computations;<br>
<br>
- for F/LOSS programs and systems, we can store the source code and the<br>
packages -- these can be re-run on emulators when the code and the<br>
systems become obsolete.<br></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Rationale for the level 0: at the moment, all TCOD CIFs are of this<br>
kind, so we are just expressing the state of the art. This assumes that<br>
referees and editors were careful enough to review the paper, check the<br>
convergence, that nobody has confused the coordinates, etc.<br>
<br>
Rationale for the level 1: we need some criteria to select structures<br>
for further processing, review, etc. We will start with the minimal set<br>
of tags (data names), and add more when necessary.<br>
<br>
Rationale for the level 2: in the nearest time, the computations can be<br>
re-run from such representation, and modified computations can be done.<br>
In the more distant future, the codes will become obsolete as Stefaan<br>
correctly predicts in his 2013-08-19 18:30 e-mail, but we can still<br>
read, analyse and parse the logs, and possibly extract more information<br>
that was parsed during the deposition.<br>
<br>
Copying and dumping all inputs and outputs captures all relevant<br>
information, allows to re-parse it in the future if necessary and<br>
accommodates any new codes and new developments of old codes.<br>
<br>
People who are not willing to share their scripts can stick to level 1<br>
as long as their publishers, funders and community do not insist on<br>
level 2 :). TCOD as a database is neutral about this (although TCOD<br>
maintainers or participants can have their strong opinions on the subject ;)<br>
<br>
Large intermediate or derivable files (electron/spin density maps, wave<br>
functions) will not be stored at the moment, and if they will, they will<br>
be added as separate files.<br>
<br>
What you think about such policy?<br></blockquote><div><br></div><div>Great job, Saulius! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Regards,<br>
Saulius<br>
<br>
PS. In a while, I'll send you a version of our poster for IUCr for the<br>
review, and some updates to the COD dictionaries.<br></blockquote><div><br></div><div>Best regards,</div><div><br></div><div>Linas </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
--<br>
Dr. Saulius Gražulis<br>
Vilnius University Institute of Biotechnology, Graiciuno 8<br>
LT-02241 Vilnius, Lietuva (Lithuania)<br>
fax: <a href="tel:%28%2B370-5%29-2602116" value="+37052602116" target="_blank">(+370-5)-2602116</a> / phone (office): <a href="tel:%28%2B370-5%29-2602556" value="+37052602556" target="_blank">(+370-5)-2602556</a><br>
mobile: <a href="tel:%28%2B370-684%29-49802" value="+37068449802" target="_blank">(+370-684)-49802</a>, <a href="tel:%28%2B370-614%29-36366" value="+37061436366" target="_blank">(+370-614)-36366</a><br>
<br>
_______________________________________________<br>
Tcod mailing list<br>
<a href="mailto:Tcod@lists.crystallography.net" target="_blank">Tcod@lists.crystallography.net</a><br>
<a href="http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod" target="_blank">http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Linas Vilciauskas<br>Postdoctoral Research Fellow<br>Dept. of Chemistry<br>New York University<br>100 Washington Square East / 830BB<br>
New York, NY 10003<br><a href="mailto:linas.vilciauskas@nyu.edu" target="_blank">linas.vilciauskas@nyu.edu</a><br>Phone: <a href="tel:%2B1-347-614-6831" value="+13476146831" target="_blank">+1-347-614-6831</a></div>
</div></div>