Tcod July 2014

tcod@lists.crystallography.net

6 participants
10 discussions

cell parameters - or others
by Daniel Chateigner 31 Jul '14

31 Jul '14

To continue on your "philosophical point" Saulius, I think it is exactly what COD-TCOD-PCOD-XCODs are useful for. In my opinion, structure optimisations or predictions can also economise experimental works or developments, provided they are enough acurate, i.e. verified against existing experiments. But they could be very prospective on both sides, i.e. point to new theoretical aspects if a definitively accurate experiment does not coincide with optimised structures, or indicate ameliorations of the experiments if a valid theoretical prediction indicate whatever exp bias. Well, both worlds have to coexist for the best of all worlds. In MPOD, most properties do not coincide with DFT predictions, from known structures. In the case of band gaps, this latter is often refined theoretically as twice or half the observed values ... values of elastic tensors in corundum have been large question of debates in the past 100 years, both exp and theo speaking. But I have to say, and to join Armel's point, I have always been surprised to see theo predictions corresponding to structures that were unstable under normal conditions, i.e. like if first principles were forgetting some thermodynamic variables as important as pressure, temperature ... I have also seen some band structure calculations, Lu2CuO4, an unstable compound up to 10GPa and 1500K, with no concern of any pressure, and while R2CuO4 (R= Y, and Ho to Tm) are needing such pressures. Such extreme cases have also to be included, would it be only to reveal mistakes or unreliability of exp and theo. daniel Le 30/07/2014 14:00, tcod-request(a)lists.crystallography.net a écrit : > Send Tcod mailing list submissions to > tcod(a)lists.crystallography.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod > or, via email, send a message with subject or body 'help' to > tcod-request(a)lists.crystallography.net > > You can reach the person managing the list at > tcod-owner(a)lists.crystallography.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Tcod digest..." > > > Today's Topics: > > 1. Re: [SPAM] Re: What structures do we accept to TCOD? > (Saulius Gra?ulis) > 2. Re: [SPAM] Re: Re: What structures do we accept to TCOD? > (Stefaan Cottenier) > 3. Re: What structures do we accept to TCOD? (Bj?rkman Torbj?rn) > 4. Re: [SPAM] Re: What structures do we accept to TCOD? > (Armel le Bail) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Jul 2014 12:12:01 +0300 > From: Saulius Gra?ulis <grazulis(a)ibt.lt> > To: Armel le Bail <Armel.le_Bail(a)univ-lemans.fr>, > tcod(a)lists.crystallography.net > Subject: Re: [TCOD] [SPAM] Re: What structures do we accept to TCOD? > Message-ID: <53D8B6E1.3030900(a)ibt.lt> > Content-Type: text/plain; charset=windows-1252 > > Hello, > > On 2014-07-30 01:02, Armel le Bail wrote: >>> My point is: the task of comparing experiment and theory (i.e. >>> comparing COD and TCOD) is a research task in its own right. >> To my knowledge, theoreticians are aware about the low quality of the >> cell parameters derived from their DFT optimizations to the point that >> they prefer to fix them to the experimental values when available. >> There is here at least a point of convergence between COD and TCOD - >> and a serious problem with the current theoretical approach ;-). > I would take a philosophical view on this subject :). In science, we are > always constrained by the limitations of our current methods, and this > is true both for XRD experiments and for DFT computations. As long as > these limitations are known and recorded, we can make useful predictions > from the experimental and theoretical results. This is what COD and TCOD > are aiming at, aren't they? > > There are cases when the limitations of the methods are not exactly > known, or are known only approximately. I hope that in these cases, > comparing TCOD and COD would bring useful insights and help to determine > those limits; and maybe to improve methods as well, both in experiment > and in theoretical approaches. > > I would expect that, in a "reliable prediction" limit, theoretical > optimisations and experimental results must agree within error bars. If > they do not, we need to investigate why. I agree that this will be a > research in its own; both COD and TCOD will record self-consistent, > state-of-the art results generated by both approaches (but we will want > to exclude sub-standard files, that's why quality criteria are important). > > If DFT computations need experimental cells for increased accuracy -- > fine, COD is free and open to provide them! Moreover, in some cases COD > *only* has cell constants and composition, since the experimental > coordinates are behind the pay-wall of proprietary journals and > databases. In these cases a DFT computation int TCOD might be the only > free data set with atomic coordinates of that particular compound! If we > could do this reliably on a large scale, TCOD would have enormous value > as a free resource, liberating crystal structures that many people > otherwise have no access to, or which we may not use as we would wish > due to license limitations. > > Sincerely yours, > Saulius > -- ---------------------------------------------------------------------- Daniel Chateigner Professeur, Université de Caen Basse-Normandie http://www.ecole.ensicaen.fr/~chateign/danielc/ ---------------------------------------------------------------------- Editor: "Combined Analysis", Wiley-ISTE: http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1848211988.html Workshops on Combined Analysis: http://www.ecole.ensicaen.fr/~chateign/formation/ Advisory Board: Zeitschrift für Kristallographie ---------------------------------------------------------------------- Address: CRISMAT-ENSICAEN and IUT-Caen, Université de Caen Basse-Normandie, campus 2 6, Bd. M. Juin 14050 Caen, France tel: 33 (0)2 31 45 26 11 fax: 33 (0)2 31 95 16 00 daniel.chateigner(a)ensicaen.fr ---------------------------------------------------------------------- Open Databases: Full-Profile Search-Match: http://cod.iutcaen.unicaen.fr/ Material Properties Open Database (MPOD): http://www.materialproperties.org/ Crystallography Open Database (COD): http://sdpd.univ-lemans.fr/cod/ Theoretical (TCOD): http://sdpd.univ-lemans.fr/cod/tcod/ Predicted (PCOD): http://sdpd.univ-lemans.fr/cod/pcod/ ----------------------------------------------------------------------

1 0

Examples of input and output data for various QM codes?
by Saulius Gražulis 31 Jul '14

31 Jul '14

Dear colleagues, I am now starting to investigate how to extract information automatically from QM code outputs. The tools for which I have found so far for this job are jumbo-converters, cclib, Torbjörn's et al. vasp2cif and, of course, the good old Perl :). To get some impression of how the inputs and outputs look like, I have run a bunch of open source codes on my computer (so far, abinit, mopac7, mpqc, nwchem, psi3 and quantum-espresso -- in alphabetic order, these are those that could be be installed using the default package repositories on Ubuntu 12.04). I managed to run some examples and tutorials provided with each of these packages (http://www.crystallography.net/archives/2014/software/qchem/), and started to play with the extraction of the data there (http://www.crystallography.net/archives/2014/software/qchem/abinit/make/bin…) a couple of weeks ago. We have also discussed with Peter that I could also try to make Quantum Espresso log analyser using Jumbo-converters, unless, of course, QE has some log converter already. I am, however, not an expert in QM computations, so I am not in a position to run a really good optimisation, the one that would be worth depositing to TCOD. May I therefore ask you to send me some samples quality runs of your favourite codes -- preferably the open source ones, and, if possible, the ones which I may expose publicly. Maybe some of your students make standard exercisers which you could share. Quantum-espresso and NWChem are especially interesting in this context here ;) If you would prefer that the files you send me are kept private, please let me know about this. VASP inputs and outputs would be handy as well; though I can not rerun them I can analyse the logs. And I have an old example from Stefaan using W2K (9008878_W2K_PBE_06.5_00250.tar.gz), but I would appreciate a citation of the command that was used to run it. I will then try different data extraction methods and see how they can be integrated into the TCOD deposition system. Sincerely yours, Saulius -- 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

1 0

Re: [TCOD] What structures do we accept to TCOD?
by Björkman Torbjörn 31 Jul '14

31 Jul '14

Hi Saulius, >> that would simultaneously store all the relevant data and be the >> simplest for the uploader. But then that is probably some time >> away... (although I have some work in progress for VASP) > >Very valuable! If you could share your code with the TCOD, this would be >a great contribution. It is a program called vasp2cif originally by Peter Larsson (now at NSC in Linköping, Sweden) and then extended by me. One version is available at https://github.com/egplar/vasp2cif although I know that I have done things to it later that have not yet ended up there (mostly due to lack of time on my part to learn to use git). So far it only extracts the geometry, not the "clever" stuff, like convergence parameters, because the last time I had time to do something with this the DFT dictionary was still in a fairly volatile state... but it is simple for me to do. I can quickly (="a day of work or so") make a version that takes an OUTCAR (main output file of VASP) and produces a CIF file with all that we are interested in. This can be expected to be ready rather soon (="when I have managed to clear some time for this" \approx "within a month"). Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland ________________________________________ Från: tcod-bounces(a)lists.crystallography.net [tcod-bounces(a)lists.crystallography.net] för Saulius Gražulis [grazulis(a)ibt.lt] Skickat: den 31 juli 2014 12:31 Till: tcod(a)lists.crystallography.net Ämne: Re: [TCOD] What structures do we accept to TCOD? Hi, Torbjörn, On 2014-07-31 11:33, Björkman Torbjörn wrote: >> The entire instruction file is something which in Saulius' scheme >> is at >>> level 2. It is definitely the ideal situation if every entry >>> would have all information up to level 2. But while for some >>> codes that will be straightforward (one input file and go), for >>> others it would require many input files and a sequence of >>> commands (with varying options) to go from the initial structure >>> to the optimized one in a reproducible way (and as codes evolve, >>> the input might quickly get incompatible). Strictly requiring >>> that all this information is present, would scare away many >>> entries that would nevertheless have been useful. > I think I need a clarification here. The question of levels is > completely apart from the CIF dictionary, right? Yes, indeed. The levels are TCOD specific agreements. They are not encoded in CID dictionaries but will rather be encoded in deposition software. E.g. if we agree that for published structures level 0 is OK, then the checker will accept structures without the _dft_total_energy data item, but will insist on _journal_... or _journal_paper_doi being present. On the other hand, for personal communications, or for large-scale computation projects that might wish to contribute, we may not have DOI but will then insist to have residual forces and total energy (level 1 description). And so on. > Inclusion of the full input file is definitely a good idea, if > possible, but I don't think that this should be enforced at the > submission stage. Sure. This would be a level 2 (full description) and is nice to have, but I am realistic that many people may not want or will not care to provide this information. > Actually, the best solution is of course to code up an interface that > just sucks all the data straight from uploaded input/output files I'm right now working on this. > that would simultaneously store all the relevant data and be the > simplest for the uploader. But then that is probably some time > away... (although I have some work in progress for VASP) Very valuable! If you could share your code with the TCOD, this would be a great contribution. >>> Items that have been suggested so far for level 0 are: >>>> *cif of the final structure >>>> *publication reference >>>> *level of theory (XC within DFT, or name of method if not DFT) >>>> *full optimization or only positions > I think this is a pretty good list. Me to. Thanks for the list. This is a very valuable input and permits me to start formalising the TCOD requirements at the dictionary and cif checker software levels. Sincerely, Saulius -- 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(a)lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod

1 0

TCOD dictionary organisation.
by Saulius Gražulis 31 Jul '14

31 Jul '14

Dear TCODers, I am now updating tcod dictionaries to add more descriptions and merge parameters provided by you in this mailing list, and used in other projects (http://quixote.wikispot.org/Prototype_data). After the recent updates, some tags appear to be both in cif_tcod.dic and cif_dft.dic (http://www.crystallography.net/tcod/cif/dictionaries/). After some consideration I start thinking that it would be reasonable to keep cif_tcod.dic only for general meta-data tags (such as computation method, one of which may be DFT, and program name, version, etc.) All DFT-specific data items would then go into cif_dft.dic. Such arrangement would permit independent development of dictionaries in parallel, allow introduction of new dictionaries (say one for molecular mechanics or for non-DFT QM methods) and replacement of dictionaries without breaking compatibility of the archive (e.g. if we ever need a cif_dft2.dic dictionary, it can exist in parallel with the older cif_dft.dic and reuse the cif_tcod.dic) If nobody is against, I'll distribute the tags into their respective dictionaries. Please let me know if you find this OK or not. Regards, Saulius -- 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

1 0

Re: [TCOD] What structures do we accept to TCOD?
by Björkman Torbjörn 31 Jul '14

31 Jul '14

Dear all, > The entire instruction file is something which in Saulius' scheme is at > level 2. It is definitely the ideal situation if every entry would have > all information up to level 2. But while for some codes that will be > straightforward (one input file and go), for others it would require > many input files and a sequence of commands (with varying options) to go > from the initial structure to the optimized one in a reproducible way > (and as codes evolve, the input might quickly get incompatible). > Strictly requiring that all this information is present, would scare > away many entries that would nevertheless have been useful. I think I need a clarification here. The question of levels is completely apart from the CIF dictionary, right? Inclusion of the full input file is definitely a good idea, if possible, but I don't think that this should be enforced at the submission stage. Actually, the best solution is of course to code up an interface that just sucks all the data straight from uploaded input/output files, that would simultaneously store all the relevant data and be the simplest for the uploader. But then that is probably some time away... (although I have some work in progress for VASP) > Items that have been suggested so far for level 0 are: > *cif of the final structure > *publication reference > *level of theory (XC within DFT, or name of method if not DFT) > *full optimization or only positions I think this is a pretty good list. Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland

2 1

Re: [TCOD] What structures do we accept to TCOD?
by Björkman Torbjörn 31 Jul '14

31 Jul '14

--- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland >> My point is: the task of comparing experiment and theory (i.e. >> comparing COD and TCOD) is a research task in its own right. > > To my knowledge, theoricians are aware about the low quality of the > cell parameters derived from their DFT optimizations to the point that > they prefer to fix them to the experimental values when available. I would agree with Stefaan that this is a problem we largely know how to deal with, if all you want is lattice constants for a single compound. But in practice there are often associated complications, such as the need to simultaneously describing two different structures at an interface, and then you often need to weigh a lot of different factors together to get the best approximation to the whole problem. It is fairly common that this balance in the end produces the solution "just fix the lattice constant to their experimental values", since that is typically good enough and well controlled and easily reproducible. > This triggered another thought: isn't the information whether only > positions were optimized and/or whether the full cell shape was > optimized as well level-0 information? If we see only the cif without > this information, then there is not much that can be concluded about > such an entry. And as a corollary: doesn't that imply that there is no > place in TCOD for DFT calculations that start from the experimental cif > without any subsequent optimization? What do others think? Hmm... actually, it never even occured to me that someone might want to submit an only partially optimized structure. I guess that means that I think that there is no place for such calculations in TCOD. It seems very difficult to estimate the practical value of such a calculation and I can't see myself being very interested in the outcome. But there may be folks out there with a different viewpoint, I can guess that there could be a use for calculations like that for things like molecular crystals, where the molecules are easy and their weak interaction (which will determine the cell shape) is hard, whereas experimentally the cell shape is easier (I guess, but correct me if I'm wrong). Anyway my instinctive vote is No. Cheers, Torbjörn _______________________________________________ Tcod mailing list Tcod(a)lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod

4 5

Re: [TCOD] [SPAM] Re: Re: What structures do we accept to TCOD?
by Björkman Torbjörn 31 Jul '14

31 Jul '14

Hi, MaterialsProject is definitely not open in any sensible definition of the word. It also has a "semi-commercial" aspect (which has in principle nothing to do with openness), they run research for industry who then have a time-limited embargo on what came up (and, needless to say, they patent anything useful) before it can be added to their "publically" "accessible" database. The project also seems quite top-heavy in its decision processes, so respectless, open-minded experimentation with the data seems unlikely to come out of the team itself either. I have followed this project from a distance with a constantly decreasing enthusiasm. An older (the oldest in condensed matter theory?) project in this genre is Mattias Klintenberg's "Electronic structure project" http://gurka.fysik.uu.se/esp/. This data is unfortunately also not very accessible either (one reason being that it obeys the most important bit of the ICSD license and does not list geometries). It also only has one-at-a-time access and seems unlikely to be opened up in the forseeable future, among other things because it does not relax the structures but uses the ICSD data directly. In fact, the ICSD license explicitly forbids you to store the database in a different format, so without their express permission (which was very easily obtained, though, I got some very positive reactions when I contacted them about my own project) you can't even begin to do your calculations. I think that ICSD could get the whole of the MaterialsProject off the web if they wanted to, relaxed structures and all, since it is all derived from an illegally obtained version of ICSD (i.e. their version stored in a different format). It is no small amount of irony that the MaterialsProject impose precisely that very same restriction on their users... Anyway, you don't have to think about these things for long before you realize that it is absolutely necessary to have a good open alternative if you want to do research. Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland ________________________________________ Från: tcod-bounces(a)lists.crystallography.net [tcod-bounces(a)lists.crystallography.net] för Saulius Gražulis [grazulis(a)ibt.lt] Skickat: den 30 juli 2014 17:13 Till: Stefaan Cottenier; tcod(a)lists.crystallography.net Ämne: Re: [TCOD] [SPAM] Re: Re: What structures do we accept to TCOD? Hi, On 2014-07-30 12:21, Stefaan Cottenier wrote: > It might be useful to know that others have done already exactly this. > www.materialsproject.org is a free database of VASP calculations for > essentially all relevant ICSD entries. They list not only the unit cell > info after optimization, but also the starting point... which is exactly > what you find in ICSD. Free to read for anyone. (I once asked them > whether they asked permission to ICSD to do this. The answer was: no, we > just did it, and so far nobody complained.) Just looked into the www.materialsproject.org web site. This might be a useful project, but nowhere close to being "free" (as in "freedom"): a) Terms and conditions: "You agree not to use automated scripts to collect large fractions of the database and disseminate them." (https://www.materialsproject.org/terms). b) Even to look at it, you need to log in (no data is available otherwise -- or at least I could not find it). When I tried to register using my gmail account, Google reports: "Materialsproject.rpxnow.com would like to: View the email address associated with your account; - View your basic profile info". Why would the MP want to dig into my profile just to let me to view a sample of the MP data?! I wonder if MP makes a database of materials properties, or a database for direct marketing? Needless to say, I declined. The declared MP terms and conditions fall short of any open data definition (e.g. as in http://opendefinition.org/), IMHO. That's probably why ICSD did not complain -- the Materials project actually exposes nothing on the Web. This is not to say that they are doing anything bad or not useful under special circumstances, but we may not/can not reuse the MP data for TCOD, so it is of little use for us. *COD databases are completely different in this respect -- they are indeed free. Regards, Saulius -- 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(a)lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod

1 0

Re: [TCOD] [SPAM] Re: What structures do we accept to TCOD?
by Björkman Torbjörn 31 Jul '14

31 Jul '14

Dear all, It seems that I forgot to add the list to recipients... Armel, do read on, I added some things. I would say no, for two reasons. The first is practical: It would require the possibility to somehow automatically determine a suitable experimental reference structure. I don't think that this is possible, since the criteria go way beyond "purely crystallographic" considerations (Fobs et cetera). You'd need to know that the sample is actually pure enough (in DFT we always have perfect samples...), precisely how were samples prepared, what the temperature effects are like and so on... The second is from basic principles. I think that would be going into data analysis, whereas the point of TCOD is just storage of data, with quality control done within DFT itself (to the extent that this is possible). Requiring a comparison to experimental data to me makes about as much sense as requiring supporting DFT calculations for inclusion of experimentally determined structures in COD. All the arguments against such a procedure apply equally well in both directions. There is also the problem that, in terms of Saulius checkpoint list, we also have the possibility b''') Neither experiments or theory have any problems, but you are comparing apples and bananas due to too little information being available on either side. For example, a DFT calculation (which assumes a temperature of 0K) would tell you that the experimentally observed bcc titanium is nonsense, whereas it is in fact a high temperature phase that is stabilized by phonon-phonon interactions. If temperature data would be missing (or, worse, being set to some default ~300K), this would generate confusion. The only time that this is straightforward is in cases where a lot is known and everyone knows the correct answer anyway, but then these are the cases we are trying to venture beyond... It would of course be very nice to at some point have a "gold standard" database, containing only structures that are exceedingly well known and understood both from the points of theory and experiment, but I don't think that either COD or TCOD should be that database. Regards, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland ________________________________________ Från: tcod-bounces(a)lists.crystallography.net [tcod-bounces(a)lists.crystallography.net] för Armel le Bail [Armel.le_Bail(a)univ-lemans.fr] Skickat: den 30 juli 2014 01:02 Till: tcod(a)lists.crystallography.net Ämne: Re: [TCOD] [SPAM] Re: What structures do we accept to TCOD? Hi, > My point is: the task of comparing experiment and theory (i.e. > comparing COD and TCOD) is a research task in its own right. To my knowledge, theoricians are aware about the low quality of the cell parameters derived from their DFT optimizations to the point that they prefer to fix them to the experimental values when available. There is here at least a point of convergence between COD and TCOD - and a serious problem with the current theoretical approach ;-). Best, Armel _______________________________________________ Tcod mailing list Tcod(a)lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod

3 2

Fwd: some discussion topics related to TCOD
by Stefaan Cottenier 31 Jul '14

31 Jul '14

(as it seems there have been technical problems about TCOD, I'm not sure whether this 3-months-ago mail actually reached all or you or not. I just resend it.) -------- Original Message -------- Subject: some discussion topics related to TCOD Date: Fri, 24 May 2013 14:34:08 +0200 From: Stefaan Cottenier <Stefaan.Cottenier(a)UGent.be> To: tcod(a)lists.crystallography.net Dear colleagues, Today, we held a group discussion at CMM (http://molmod.ugent.be) about TCOD from the perspective of users and/or structure donators. That did not lead to clear conclusions, but rather to a series of thoughts that can be a starting point for further discussions or actions. I'll list those here (I guess that is what this mailing list is meant for): 1) You are probably aware of other database initiatives for computed crystal structures. Is there a vision on whether TCOD wants to 'compete' with those, or whether TCOD tries to fill a niche that is not served by other databases? For instance, consider https://www.materialsproject.org/. This is a database that aims doing a VASP geometry optimization for every structure in ICSD, starting from the ICSD cif (quite ironically, you can read their starting geometry (=ICSD info) for free, without having an ICSD yourself...). They use their own dedicated supercomputer infrastructure to run all this, and upload only results achieved by themselves. No input by others, this in order to keep control over quality and consistency. It has over 30.000 crystals by now, and apart from the structure info also computed properties are being added. I quote here a paragraph from a project proposal which we submitted earlier this year, and which contains info/references about other databases: "As is often the case for revolutions, this idea has been realized simultaneously and more or less independently at several places, emphasizing different aspects. The Materials Project [Jai11,MP] is an initiative at MIT, where basic properties of all crystalline solids documented in the (experimental) Inorganic Crystal Structure Database (ICSD) [ICSD] have been computed by DFT. The computed formation energies are used to construct secondary data bases of binary and ternary phase diagrams [Ong08, Jai11b]. Similar initiatives, each with their own focus and in different stages of growth are AFLOWLIB [Set10,Cur12] (Duke University), OQMD [Wol12] (Northwestern University) and CompES [CES] (NIMS, Japan). Other database initiatives that emphasize collaborative data sharing (see also Sec. 2.3, WP3) are ESTEST [Yua10,Yua12] at UC Davis (US), the Computational Materials Repository (CMR) [Lan12] at DTU (Denmark) and the AIDA environment [Koz13]." [Jai11] A. Jain et al. Computational Materials Science 50 (2011) 2295 [Jai11b] A. Jain et al., Physical Review B 84 (2011) 045115. [Ong08] S. P. Ong, L. Wang, B. Kang, G. Ceder, Chemistry of Materials 20 (2008) 1798 [Set10] W. Setyawan, S. Curtarolo, Computational Materials Science 49 (2010) 299 [Cur12] S. Curtarolo et al., Computational Materials Science 58 (2012) 227 [Wol12] Open Quantum Mechanical Database, http://wolverton.northwestern.edu/oqmd (no public access yet) [CES] http://caldb.nims.go.jp/index_en.html (Y. Chen, A. Nogami, H. Ohtani, N. Tatara) [Yua10] G. Yuan, F. Gygi, Computational Science & Discovery 3 (2010) 015004 [Yua12] G. Yuan, F. Gygi, Computer Physics Communications 183 (2012) 1744 [Lan12] D. Landis et al., Computing in Science and Engineering, nov/dec 2012, p. 51 (http://dx.doi.org/10.1109/MCSE.2012.16) [Koz13] B. Kozinsky, N. Marzari, N. Bonini, J. Garg, G. Pizzi, A. Cepellotti, M. Fornari, contributions at the MRS Fall meeting (Boston, Nov. 2012) and the DPG Spring meeting (Regensburg, March 2013). (2) From our perspective, we don't understand the need to separate experimental and computational databases. As long as every structure is properly tagged as 'experimental' or 'computed', we see no reason to separate them. It will only lead to the burden of having to run queries twice. In any case, a unified search web page that searches in both data bases simultaneously seems useful to us (that is, de facto, treating (T)COD as one database). (3) Quality control. If a deposited computed structure has been published, the reference to the publication serves as quality control. That's probably similar for deposited experimental structures, isn't it? If a computed structure has not (yet) been published, how to assess its quality? Well, let us turn the question around: if a not yet published experimental structure is deposited, how do you judge its quality...? It makes sense to do it in the same way: as long as basic information is provided on how the calculation has been done, later users should make their own judgement. (4) A quality control measure that could make sense for both experimental and computed structures, is to allow people to add remarks that appear on the web page of that structure ('considering the small basis set that has been used, I do not trust this result', or 'this result has been contradicted by <ref>'). Such information by the community can help people who are not experts in either computing or measuring crystal structures to decide to which extent they can trust a particular result. (Another variant is a feature on the web page of each structure to flag it if you have doubts, such that experts can look at it). (5) COD has cifs as entries only. If you want to go as far as including input info to reproduce each calculation, it might be hard to stick cifs-only for TCOD. It will then be necessary to link additional files to the cif of each entry. (6) We are split over whether it makes sense to require that each deposited calculation is exactly reproducible. Some basic information should be given, of course. This will be mainly information about the method that does not depend on the specific implementation (code). Furthermore, the main technical input parameters that are specific for the code used, should be given as well (if you want to do that in a structured way, you will immediately hit the problem that the required set of numbers will be a different kind of set for every other code...). Third in line should then be a free field for 'any other special settings' that could apply. With this kind of info, people can reproduce to a large extent (95%) the same calculation. If you want to have it reproduced exactly, then much more input (files) will be required. Which might not be worth the effort. (7) One of our enthusiastic PhD students with many years of experience in web design and databases immediately had a mental map about how to implement an automated version of (6) -- if the TCOD-team is willing to take him aboard to code that, he'll probably agree ;-). (8) In any case, it should be clear for the one who provides the structure, what exactly is requested. A web form where the information under (6) can be filled out (or the automated tool of (7) that extracts all this info from the output of each mainstream code) will be required in order to have consistent data. (9) Which kind of computed structures will TCOD accept? Ground state structures, obviously? Metastable structures probably as well? Also if they are not dynamically stable (soft phonon mode)? (that is not routinely examined) And what about transition state structures? (never observable in experiment, yet very useful to know -- and hard to find -- in order to understand reactions) If the latter are allowed, then they should be tagged as such. Best regards, Stefaan -- Stefaan Cottenier Center for Molecular Modeling (CMM) & Department of Materials Science and Engineering (DMSE) Ghent University Technologiepark 903 BE-9052 Zwijnaarde Belgium http://molmod.Ugent.be http://www.ugent.be/ea/dmse/en email: Stefaan . Cottenier /at/ UGent . be

4 12

TCOD dictionaries and data presentation -- 3 levels of description
by Saulius Gražulis 29 Jul '14

29 Jul '14

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. 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; -- 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. 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? 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. -- 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

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Tcod July 2014