Tcod

tcod@lists.crystallography.net

33 discussions

Re: [TCOD] Tcod Digest, Vol 9, Issue 4
by Daniel Chateigner 06 Nov '14

06 Nov '14

Hi All, Not being an expert in DFT or whatsoever calculation approach, I'll place my two cents here, perhaps more related to physical properties, and giving only general remarks: In my opinion, we should not remove too much tags, and in particular the ones that are a bit ambiguous. If they are there, it has been at some times on purpose. If scientists post reflections do not use it any longer (because badly defined, software-dependent, not enough strict ...), this has to be for good reasons, and certainly not because journals don't mention it. Journals are more and more financial dependent and rough at carefully checking their own contents. That is why you can see more and more comments, corrections, retractions, plaggiarism and falsificated data in the literature and at the end of the periodicals. Even in well recognized ones, driven by scientific societies and international unions. Couldn't we envisage instead TCOD as a large way to also check for given data ? Then we need as much as possible details, like diffractometer configurations are required to replicate a given structure refinement from raw data, first-principle calculations need to specify amap the way the calculations were carried out. This is "their" experiments. Detailed exp (in the code configuration meaning) details will be very valuable also to understand the physical principles that bias some result, they are fundamental to know if a calculation method is founded or needs some ameliorations. For instance, elastic properties or band gaps in many materials, as calculated from first principles, are usually scattered among authors and experimentally measured ones on single crystals. I.e. something is going wrong, either in the measurements or in the simulations. How can we progress if insufficient data on the measurement methods and/or simulations are given ? again, only my two cents ! cheers to all daniel Le 06/11/2014 08:02, 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: Questions still left regarding TCOD dictionaries > (Lubomir Smrcok) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Nov 2014 08:00:32 +0100 (CET) > From: Lubomir Smrcok <Lubomir.Smrcok(a)savba.sk> > To: Linas Vilciauskas <linas.vilciauskas(a)nyu.edu> > Cc: tcod(a)lists.crystallography.net > Subject: Re: [TCOD] Questions still left regarding TCOD dictionaries > Message-ID: > <1512912744.72723058.1415257232630.JavaMail.zimbra(a)savba.sk> > Content-Type: text/plain; charset="utf-8" > > The more you store, the less you get ... :-) > lubo > > > ----- Original Message ----- > > From: "Linas Vilciauskas" <linas.vilciauskas(a)nyu.edu> > To: tcod(a)lists.crystallography.net > Sent: Wednesday, November 5, 2014 6:53:26 PM > Subject: Re: [TCOD] Questions still left regarding TCOD dictionaries > > Dear Saulius and TCOD'ers > > One of the first questions for me when looking at the new dictionary was the _tcode_structure_type entry. I think we are mixing up several terminologies from the experimental and computational worlds which simply do not make sense. I understand the " crystal-ground-state" and " crystal-excited-state". But honestly have no idea what does the " crystal-metastable" mean, especially when talking about a life-time? Kinetics is virtually inaccessible in the kind of simulations we are talking about and should be left out from the discussion. The theorists by metastable structure usually mean that it is a stable structure (local minimum) on the potential (free) energy surface but it is not a global minimum on that surface. The two might have a high barrier separating (+ there might be defects etc.) them, which for experimentalist, makes it to show up as a kinetically stabilized (metastable) structure in experiments with finite (seconds to thousands of years) life-time. So what experi > mentalists mean as a metastable structure could be a nice local minimum (same as " crystal-ground-state") in DFT which depending on the method might even show up as a global minimum depending on the theory level used or e.g. inclusion of the entropic effects. > > My underline is that in DFT there is nothing like life-time... > > I'm also not entirely sure what is the difference between the " crystal-soft-phonon" and " crystal-transition-state". Is there are going to be a cut-off frequency for phonons to call them "soft"? Or imaginary frequency phonons? Which would imply that they have a negative Hessian eigenvalue? Would it make it a transition state then? > > If one includes the transition states, I think one has to add a massive dictionary for describing the plethora of methods to get that transition state. I think at some point it will become intractable... My suggestion would be to get rid of all these keywords: crystal-metastable, crystal-soft-phonon, crystal-transition-state, vacuum-ground-state, vacuum-excited-state, vacuum-metastable, vacuum-transition-state completely. > > At the end of a day it is a Crystallographic database and it should have a clearly defined face and purpose meaning that we should not care(accept) about molecules (vacuum structures). > > > On Wed, Nov 5, 2014 at 11:34 AM, Bj?rkman Torbj?rn < torbjorn.bjorkman(a)aalto.fi > wrote: > > > Dear all, > > Stefaan supplies good information for everything as usual, so just a couple of remarks here. > >>>> f) If e) is "yes", then we can talk about "microcycles" (electron w/f >>>> refinement) and "macrocycles" (nuclei/cell shifted in each >>>> "macrocycle"). We could also document total energy changes in all these >>>> cycles, to monitor the convergence, as I suggest in >>>> _tcod_computation_cycle_... data items. Is such view acceptable? What is >>>> the terminology used in different codes? Will such table be useful? Will >>>> it be easy to obtain from most codes? >>> I advice to stay away from that. Your view is correct, but this >>> information is often not mentioned even in papers. Documenting such >>> changes would be arbitrary, to some extent. The final relaxed geometry >>> is well-defined, but what do you take as the unrelaxed starting point...? >> The idea is that the unrelaxed structure starts somewhere at high >> energies, and then it converges to low energy that no longer changes >> significantly with refinement cycles. For me, this would be evidence >> that the process has converged. I guess when one does a calculation, one >> looks into such energy behavior traces, doesn't one? >> >> If so, then it makes sense to have tools to record the traces in CIFs, >> as an evidence of convergence and convergence checks. >> >> I also want to point out that the presence of the data items (for energy >> tables) in the dictionary does not imply any obligation to use them. Any >> CIF will be correct and valid without them. Its just if we decide to >> include them, there will be a publicly announced way to do this. > Here I would say that what one normally pays attention to is just the residual forces/energy changes at convergence, documenting the starting point is not something that is normally done. We should also beware a little here since the starting point is very often data straight out of proprietory databases... it might well lead to a lot of trouble. > > > > > I agree with Stefaan and Torbj?rn. The only thing which might be useful is the final structure and some information on residual(maximum) forces and maybe energy changes... > > > <blockquote> > > >>>> Is it enough for DFT to specify >>>> just an energy cut-off, assuming plane wave bases (for a given >>>> pseudopotential), or are there different possible bases also among plane >>>> waves (I guess there should not be, but maybe I'm missing something...)? >>> For plane waves the energy cut-off is the only quantity. But there are >>> many other types of basis sets that are no plane waves. For these, more >>> specification might be needed (although often they are contained in the >>> published definition of the basis set). >> I see. OK, I so understand that DFT can work both with PW and localized >> bases, and the exact basis should be specified in the input file (and >> might be documented in the CIF). > There are even "hybrid" schemes, like anything based on the muffin-tin geometry (LAPW, LMTO, ...) which come with a local and PW-like part and where the enumeration of basis functions may be by the PW's (like LAPW) or by the local part (like LMTO). There are wavelet-based codes which I have no idea how they converge. And so on. We have unfortunately a rather messier situation than the quantum chemists. > > </blockquote> > > > I think it is inevitable to use strings for the basis set description... e.g. CP2K uses Plane waves and Gaussians at the same time, so one needs both the cut-off and the gaussian basis set name. Wavelets are even more messy since it is a kind of multi-resolution method with several parameters. > > <blockquote> > > > >>>> n) Am I correct to assume that the "total energy" reported by codes will >>>> always be the sum of separate energy terms (Coulomb, exchange, >>>> 1-electron, 2-electron, etc.)? Is there an interest to have them >>>> recorded in the result data files (CIFs) separately? If yes, what is the >>>> "Hartree energy" (is it a sum of all single electron energies in the SCF >>>> for each of them?), "Ewald energy" (is it the electrostatic lattice >>>> energy, obtained by Ewald summation?) and the rest in the values from >>>> the AbInit output file? Are these terms consistent across QM codes? >>> Also here I think this is asking for way too much detail. Most codes can >>> indeed split up the total energy in many contributions, but papers >>> usually do not report that (only in the special cases when there is >>> useful information in the splitting). If papers don't do it, databases >>> shouldn't either -- that feels as a sound criterium. >> Interesting idea. Well, that makes our life easier. > It is in fact worse than that, because the precise nature of this split depends on technical details such as how you solve the Poisson equation and how you treat core states. This varies between the codes, so there is not in general any possibility to make a sound comparison between different methods for these partial energies. So I don't think anything much is gained by documenting them. > > </blockquote> > > > Completely agree. Different terms can be evaluated using different methods so the comparison many cases will not make sense. > > <blockquote> > > ... >> May I disagree to some extent. If we can do better checks than journals >> do, why shouldn't we? That would be a useful tool, a help for journal >> reviewers, and one possible way to improved the situation. > ... >> In short, I think that it would be quite useful to have uniform *actual* >> convergence criteria in the CIF output, and check them before inserting >> computations into TCOD, like we check crystal structure symmetry, bond >> distances, parameter shifts or R-factors. > Here I tend to agree, but at the same time I would not want us to impose too draconic criteria for acceptance, as long as the obtained result is documented. Perhaps some two-level system with "hard" acceptance criteria and a "warning" level would be good? > > </blockquote> > > > That's true. There might be some problem with converging the geometry for example (high residual forces on atoms(cell)) which might be checked against some value. But on the other hand if the R- factor is high (wrt to the experiment) what does it mean: maybe the DFT model is not correct, or maybe it is not correct for this type of system? Shall we accept an entry on naphthalene, anthrecene or pentacene calculated using plain PBE? Is there an ultimate method which would be able to calculate everything correctly? The answer being - No... > > <blockquote> > > > Hi, Stefaan, > > many thanks for your quick and very informative answer. I'll adjust the > dictionaries according to it. Below are some of my comments. > > On 2014-11-05 13:33, Stefaan Cottenier wrote: >> Let me comment on those questions that I can do on the spot, without >> looking into the dictionary yet : >> >>> a) the units of energy that we started to use in the dictionaries are eV >>> (electron-Volts). For distances, we should probably use Angstroems, >>> since then we can easier compare computation results with >>> crystallographic experimental data. This naturally suggests units for >>> forces as eV/A. Is that OK, or should we better use SI units of similar >>> scale (say aJ -- atto-Joules, on the similar scale)? The only problem I >>> see with eV is that it is measured, not defined from the basic SI units >>> ( http://en.wikipedia.org/wiki/Electronvolt , >>> http://physics.nist.gov/cuu/Units/outside.html ). >> Although SI units would be in principle the good choice, nobody uses >> them in this context. At least eV and Angstrom have a special status >> ('tolerated units' within SI), hence allowing eV, Angstrom and therefore >> eV/A for forces is a fair compromise. > Good. So we stay with eV and A, with eV/A for forces, as already > documented in our dictionaries. > >>> b) Is nuclear electric dipole moment used/necessary for DFT computations >>> (_dft_atom_type_nuclear_dipole)? >>> >>> c) If b) is "yes", what units we should use for electric dipole (and >>> higher moments) -- Debayes, e*A (amount of unit charges times >>> Angstroems), or something else? >> There must be some kind of confusion here -- my old nuclear physics >> courses always emphasized that nuclei do not have an electric dipole >> moment. Either you mean magnetic dipole moment or nuclear quadrupole >> moment? Anyway, nuclear properties are never required for DFT >> calculations as such, but they can be used to convert DFT-predictions >> into quantities that are experimentally accessible. I don't see the need >> to keep track of this, however, in a computational database. > OK, this is a gap in my education -- I must have overlooked the zero > nuclear electric dipole during my university years... > > Setting aside the theoretical question whether the quarks can move in > such a way as to give non-zero dipole, I remove the > _dft_atom_type_nuclear_dipole as lacking theoretical justification and > empirical evidence. For magnetic dipole, a > _dft_atom_type_magn_nuclear_moment could be introduced if needed (for > orbital and spin magnetic moments the data names are already there). > >>> e) If I understand correctly, DFT and most other QM methods operate >>> under Born-Oppenheimer approximation; under this approximation, electron >>> densities (electron wave-functions) are optimised to minimal energy at >>> fixed nuclei and unit cell parameters, and when this converges, the >>> nuclei parameters and/or cell constants are changed slightly (e.g. along >>> gradients), and the electron energy is minimised again. Is this a >>> correct view? Is it a universal situation across QM codes? >> Yes, correct. It is pretty universal. There some special-purpose >> applications that do not make the born-oppenheimer approximation, but >> that's really a minority. > OK. Thanks for confirmation. > >>> f) If e) is "yes", then we can talk about "microcycles" (electron w/f >>> refinement) and "macrocycles" (nuclei/cell shifted in each >>> "macrocycle"). We could also document total energy changes in all these >>> cycles, to monitor the convergence, as I suggest in >>> _tcod_computation_cycle_... data items. Is such view acceptable? What is >>> the terminology used in different codes? Will such table be useful? Will >>> it be easy to obtain from most codes? >> I advice to stay away from that. Your view is correct, but this >> information is often not mentioned even in papers. Documenting such >> changes would be arbitrary, to some extent. The final relaxed geometry >> is well-defined, but what do you take as the unrelaxed starting point...? > The idea is that the unrelaxed structure starts somewhere at high > energies, and then it converges to low energy that no longer changes > significantly with refinement cycles. For me, this would be evidence > that the process has converged. I guess when one does a calculation, one > looks into such energy behavior traces, doesn't one? > > If so, then it makes sense to have tools to record the traces in CIFs, > as an evidence of convergence and convergence checks. > > I also want to point out that the presence of the data items (for energy > tables) in the dictionary does not imply any obligation to use them. Any > CIF will be correct and valid without them. Its just if we decide to > include them, there will be a publicly announced way to do this. > >>> h) The CML CompChem dictionary mentions SCF as a method. I know HF and >>> its modifications are SCF; is DFT technically also SCF? Are there more >>> SCF methods that are not HF? Should we include "SCF" into the >>> enumeration values of the _tcod_model as a separate model? >> 'SCF' refers only to the fact that a particular iterative solving scheme >> is used. As such, I would consider that term as being less informative >> than HF or DFT (one could even imagine to do DFT without SCF, although >> in practice this very rarely is done). > OK; so we skip SCF as a separate "model". > >>> j) I have taken the _dft_basisset_type list from >>> http://www.xml-cml.org/dictionary/compchem/#basisSet , to strive at least >>> potentially for a possibility of the CIF->CML->CIF roundtrip. The two >>> big classes of basis functions, as I have learned, are localised >>> (Slater, Gaussian) and plane wave. Should we introduce such >>> classification on top of the _dft_basisset_type enumerator? >> I don't think so. It will be implicit in the name people use for the >> basis set. > OK. The type of the basis set should be implied from the basis set date > (name, files, reference). > >>> Are >>> localised bases relevant for DFT at all? >> Yes, sure (SIESTA, for instance). > Good to know. Thanks for the info! > >>> Is it enough for DFT to specify >>> just an energy cut-off, assuming plane wave bases (for a given >>> pseudopotential), or are there different possible bases also among plane >>> waves (I guess there should not be, but maybe I'm missing something...)? >> For plane waves the energy cut-off is the only quantity. But there are >> many other types of basis sets that are no plane waves. For these, more >> specification might be needed (although often they are contained in the >> published definition of the basis set). > I see. OK, I so understand that DFT can work both with PW and localized > bases, and the exact basis should be specified in the input file (and > might be documented in the CIF). > >>> l) There are a lot of *_conv data items declared (e.g. >>> _dft_basisset_energy_conv). Are they for convergence tests? Or for >>> convolutions? What is their proposed definition? >> These are the convergence criteria, for instance: stop the iterative >> (SCF) cycle once the total energy does change by less than >> _dft_basisset_energy_conv during the last few iterations. > Perfect. Now, are these the *desired* criteria, or the *obtained* values > (i.e. actual values of the computation)? Although probably we can assume > that in any case the energy change at the end of the computation was > less than the specified _dft_basisset_energy_conv value, and the same > for other *_conv values, right? > > I'll add units and explanations to the dictionary. > >>> m) Is _dft_cell_energy the same as the "total energy" reported by some >>> codes? Can we rename it to _dft_total_energy? >> Probably yes. > Hmmm... We need some explanation in the dictionary how these values are > supposed to be used. > >>> n) Am I correct to assume that the "total energy" reported by codes will >>> always be the sum of separate energy terms (Coulomb, exchange, >>> 1-electron, 2-electron, etc.)? Is there an interest to have them >>> recorded in the result data files (CIFs) separately? If yes, what is the >>> "Hartree energy" (is it a sum of all single electron energies in the SCF >>> for each of them?), "Ewald energy" (is it the electrostatic lattice >>> energy, obtained by Ewald summation?) and the rest in the values from >>> the AbInit output file? Are these terms consistent across QM codes? >> Also here I think this is asking for way too much detail. Most codes can >> indeed split up the total energy in many contributions, but papers >> usually do not report that (only in the special cases when there is >> useful information in the splitting). If papers don't do it, databases >> shouldn't either -- that feels as a sound criterium. > Interesting idea. Well, that makes our life easier. > > On the other hand, electronic media, like database, can record and make > usable more information than a traditional paper or PDF publication. We > should not overlook such possibilities and use them when needed. > > For example, in protein crystallography, structure factors were not > reported in publications at the very beginning, due to a sheer volume of > data (a protein crystal can give you a million of unique reflections); > but today it is a must and a self-evident thing to deposit such data > electronically into PDB. > >>> o) How does one check that computation has converged on k-points, >>> E-cuttof, smear and other parameters, and that pseudopotential is >>> selected right? From the Abinit tutorial >>> ( http://flex.phys.tohoku.ac.jp/texi/abinit/Tutorial/lesson_4.html ) I got >>> impression that one needs to run computation with different values of >>> these parameters, and see that the total energy, or other gauge values, >>> no longer change significantly when these parameters are increased. Is >>> that right? If yes, are there codes that do this automatically? Should >>> we require Etotal (or coordinates') dependence on k-grid, E-cuttof, >>> smear, to check convergence when depositing to TCOD? Or should TCOD side >>> check this automatically when appropriate (say for F/LOSS codes)? >> "k-points, E-cuttof, smear and other parameters" are indeed tested as >> you describe. > OK. Thanks for clarification. > > I think it would be beneficial to have such checks included into teh > results file... > >> ... The pseudpotential can't be tested that way, what people >> usually do is to verify whether the numerically converged results when >> using a particular pseudo do agree with experiment. > I see. OK, we'll have to trust PP was selected properly. > > Actually, TCOD + COD can check the computations against empirical > (crystallographic) data -- say interatomic distances, bonds, angles, > coordination sphere geometry, etc. The results might be interesting -- > significant discrepancies will either predict unseen new phenomena or > point out at problems that can be fixed readily. > > </blockquote> > > > I commented on that before. Theory might never agree with experiment. If they agree - is it for a good reason? If they don't is the reason known? > > <blockquote> > >> Doing such tests is the responsibility of each user. In principle, >> journals should not publish ab initio results if such tests are missing. >> Journals are not that strict, unfortunately. And some researchers are >> not very careful in that respect. >> >> It's a longstanding problem, that is gradually being solved because >> computers are so fast now that the default settings of most codes are >> sufficiently accurate for many cases, even if a researcher does not >> explicitly tests it. >> >> Also here, TCOD shouldn't try to do better than the journals do. > May I disagree to some extent. If we can do better checks than journals > do, why shouldn't we? That would be a useful tool, a help for journal > reviewers, and one possible way to improved the situation. > > In crystallography, the situation is sometimes similar. IUCr journals > are very good at checking structures, but some chemical journals, even > the "high profile" ones, give you CIFs that may even have syntax errors > in them! For me, this hints that nobody bothered to look at the data > before publication. But how can the claim then that he paper was "peer > reviewed"? The text apparently was, but the data probably not. This is > not a good way in today's data-driven sciences. > > COD does checks, and we plan more -- and it helps e.g. when personal > communications or prepublication structures are deposited. My personal > experience was very positive on this -- the first personal communication > I tried to send to COD was marked as not converged properly; indeed this > was an oversight, and a couple more refinement cycles fixed the problem. > > I fund such checks to be a very useful tool, so why not having something > similar for TCOD? Especially, when we expect a large number of > structures from wide-scale computational projects, where not every > computation is checked manually. > >>> p) what are other obvious things that one could make wrong in QM/DFT >>> computations, that could be checked formally? >> That's an interesting one... With no answer from my side. If there is >> anything that can go obviously wrong, the codes will have an internal >> test for it already. > Well, an obviously wrong thing would be insufficient checks for > convergence (to coarse k-grid, to little steps of minimization, etc.). > > Usually, experienced computational chemists will check for these, but > ever so often a MSc student who is just starting to learn things will > compute a structure, and the experienced boss will happen to be in the > conference... The structure may look reasonable, especially for an > unexperienced eye, but in fact it may be inaccurate... You know what I > mean :) > > In short, I think that it would be quite useful to have uniform *actual* > convergence criteria in the CIF output, and check them before inserting > computations into TCOD, like we check crystal structure symmetry, bond > distances, parameter shifts or R-factors. > > The question is, what should be the universal criteria for QChem? > > Regards, > 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

Update of the TCOD dictionaries
by Saulius Gražulis 04 Nov '14

04 Nov '14

Dear colleagues, before we can develop software for theoretical structure checks, and before before we start ingesting large amounts of data to COD, I think we should have a first "working" version of TCOD dictionaries and agree on the most necessary data items, describing them formally. I have made today a rather large and bold update of the TCOD dictionaries. I tried to follow the comments that were inserted by you in the dictionaries, but also added some items according to my understanding. The dictionaries are updated at: http://www.crystallography.net/tcod/cif/dictionaries/ (Those who have checked out the Subversion repository, please update your working copies). I would be very grateful if you critically examine the new versions of the dictionaries and give me you feedback, suggestions and corrections. The most important questions are: a) do the data items I have added are physically correct? b) are they usual in the CompChem/DFT field, and are they convenient? Regards, Saulius -- Saulius Gražulis Biotechnologijos institutas Graičiūno 8 02241 Vilnius-28 Lietuva Tel.: vidaus BTI: 226 Vilniaus BTI: (8-5)-260-25-56 mobilus TELE2: (8-684)-49-802 mobilus OMNIT: (8-614)-36-366

1 0

Nature's "Scientific Data" publishes first computational data sets
by Saulius Gražulis 17 Sep '14

17 Sep '14

Dear colleagues, you might have noticed the news -- Nature's "Scientific Data" published their first Data Descriptor from the field of computational chemistry this week: http://www.nature.com/articles/sdata201422. As fas as TCOD goes, I wonder how these computations could/should be reflected in TCOD? We also see the example of what people are doing, so we can organise TCOD at least this good (or better :). For what I see, the publication data corresponds to our agreed level 0 description with some additional details; so if the structures were of the crystalline state, we could ingest them into TCOD at this level of detail. With levels 1 and 2, TCOD would be provide even more information for automated processing. What you think? 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] Tcod Digest, Vol 7, Issue 3
by Daniel Chateigner 25 Aug '14

25 Aug '14

Yes OQMD looks interesting, and should absolutely be linked in TCOD for the benefit of both daniel Le 09/08/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. The OQMD (Saulius Gra?ulis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 09 Aug 2014 07:30:47 -0400 > From: Saulius Gra?ulis <grazulis(a)ibt.lt> > To: tcod(a)lists.crystallography.net > Subject: [TCOD] The OQMD > Message-ID: <53E60667.7040301(a)ibt.lt> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, folks, > > a day ago I have listened to the talk about the OQMD database: > > http://oqmd.org/ > > Well, actually, Stefaan mentioned it in his excellent review e-mail > (2013-09-06 12:02) on this list, but that time there was apparently no > public access to the DB. Now there is :). > > The DB is very mature and is completely open -- so good to look at and > tp collaborate with. I got in touch with Chris Wolverton, and we will > discuss over the e-mail how to get the TCOD and OQMD cooperating nicely > (unfortunately, Chris had to leave the conference early, so we could not > speak in person). > > The TCOD's role in this situation could be to present computations in a > standardized, CIF format from various groups. In this sense TCOD could > be a useful complement for the computation-first databases, and would > provide means to search and analyze computation results made by various > groups and researchers (which is the primary TCOD intent). In any case, > the OCMD data should be represented and referenced to in TCOD as well, > what do you think? > > Have a look, and stay tuned -- and your thoughts are welcome. > > Regards, > 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

The OQMD
by Saulius Gražulis 09 Aug '14

09 Aug '14

Hi, folks, a day ago I have listened to the talk about the OQMD database: http://oqmd.org/ Well, actually, Stefaan mentioned it in his excellent review e-mail (2013-09-06 12:02) on this list, but that time there was apparently no public access to the DB. Now there is :). The DB is very mature and is completely open -- so good to look at and tp collaborate with. I got in touch with Chris Wolverton, and we will discuss over the e-mail how to get the TCOD and OQMD cooperating nicely (unfortunately, Chris had to leave the conference early, so we could not speak in person). The TCOD's role in this situation could be to present computations in a standardized, CIF format from various groups. In this sense TCOD could be a useful complement for the computation-first databases, and would provide means to search and analyze computation results made by various groups and researchers (which is the primary TCOD intent). In any case, the OCMD data should be represented and referenced to in TCOD as well, what do you think? Have a look, and stay tuned -- and your thoughts are welcome. Regards, Saulius -- Saulius Gražulis Biotechnologijos institutas Graičiūno 8 02241 Vilnius-28 Lietuva Tel.: vidaus BTI: 226 Vilniaus BTI: (8-5)-260-25-56 mobilus TELE2: (8-684)-49-802 mobilus OMNIT: (8-614)-36-366

1 0

Re: [TCOD] TCOD dictionaries and data presentation -- 3 levels of description
by Björkman Torbjörn 05 Aug '14

05 Aug '14

Dear all, Running to keep up with the discussions here... Anyway, I have started to further develop vasp2cif to also extract all the relevant DFT parameters from VASP output and Saulius is going on something similar for abinit. This made some problems apparent. Stefaan Cottenier: > Specifying the XC-functional limits us to DFT only. Perhaps the keyword > should rather be 'level-of-theory'. If a LIBXC-identifier is given, then > this implies it is DFT with the quoted functional. If the value is not a > LIBXC-identifier, it refers to a non-DFT method (Hartree-Fock, GW, > QMC,...) It might be tricky to create a relevant list of non-DFT > methods, and right now it is perhaps of limited use, but the number of > predictions by these methods is likely going to surge in coming years. I think that one puts the _tcod_model to 'DFT' here to signal that it is DFT. I like the idea of using LibXC identifiers, that way we can help the only standard naming scheme slowly solidifying. The problem with LibXC is that they only name what they have implemented, and this covers only a small portion of all the possible methods (although a very large portion indeed of the methods actually used...) For example, one of my favourite classes of methods right now, non-local correlation van der Waals functionals, are not included in LibXC and thus has no naming scheme. For that reason, I would prefer to leave the functional as a "free" string, but try to primarily use the LibXC names whenever possible. I also realize that we may need tags for (semi-)empirical dispersion force parameters, particularly the Grimme scheme which is very popular. I guess that those would be introduced on a form similar to the U and J parameters now, something like: data_dft_atom_type_grimme_C6 data_dft_atom_type_grimme_radius Concerning the number of dimensions we allow.... as someone currently working with low-dimensional crystals (2D to be precise), I am reluctant to throw these out. They are perfectly fine crystallographic objects, I think, at least I seem to spend any amount of time looking at their electron diffraction patterns... From a technical standpoint they cause not real problems, you just give the size of the simulation box. I remember putting in tags to mark up whether periodic boundary conditions were used, since there are codes that can cut these along one direction, but these still typically use a finite size simulation box (as Stefaan says, there are exceptions, but not many). The CIF format of course also requires this box size to be expressed as a lattice vector, but this is not really a problematic point, this just reflects what people mostly do anyway. Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland

1 0

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Tcod