Tcod

tcod@lists.crystallography.net

33 discussions

Re: [TCOD] SAUC database with COD cells
by Saulius Gražulis 28 Nov '16

28 Nov '16

Dear Herbert, thanks for you e-mail! On 2016-11-27 19:26, Herbert J. Bernstein wrote: > You may find the cell search at > > http://iterate.sf.net/sauc/ > > interesting. We have added all the COD cells to the PDB cells that we > had before. Indeed, this is a very interesting development. I glad you find COD useful and mention it in your work. Actually, we would need search for reduced cell in COD as well, so your method is very interesting for us! I'm CC-ing out Advisory Board to have a closer look. Cheers, Saulius -- Dr. Saulius Gražulis Vilnius University Institute of Biotechnology, Saulėtekio al. 7 LT-10223 Vilnius, Lietuva (Lithuania) fax: (+370-5)-2234367 / phone (office): (+370-5)-2234353 mobile: (+370-684)-49802, (+370-614)-36366

2 1

NOMAD metadata
by Fawzi Mohamed 30 Mar '16

30 Mar '16

Dear tcod subscribers, At the Cecam workshop Towards a Common Format for Computational Materials Science Data http://www.cecam.org/workshop-1290.html I presented the result of our effort in the NOMAD project to have a a metadata structure to describe ab-initio and atomistic simulations. A good starting point to look at it is https://gitlab.rzg.mpg.de/nomad-lab/nomad-meta-info/wikis/home and we also have a git repository to which we welcome comments/contribution. I had very constructive discussion with Saulius on tcod, CIF and how we could integrate with and support also that. He also proposed to present also here, to make you aware of our work use the mailing list as discussion place, given the presence of knowledgeable people on the metadata aspect. Hopefully we agree that the more we can share the effort, the more everybody profits. With best wishes Fawzi -- ââââââââââââââââââââââââââââââââââ Dr. Fawzi Mohamed phone : ++49-30-8413 4821 Fritz-Haber-Institut fax : ++49-30-8413 4701 der Max-Planck-Gesellschaft Faradayweg 4-6 e-mail: fawzi.mohamed(a)fhi-berlin.mpg.de D-14 195 Berlin-Dahlem / Germany -------------------------------------------------------------------- WWW: http://www.fhi-berlin.mpg.de/th/th.html ----------------------key:1-0.0735-11600-23.05:fhi------------------

1 0

Re: [TCOD] Tcod Digest, Vol 12, Issue 1
by Daniel Chateigner 26 Jan '16

26 Jan '16

looks nice, good job ! just: 'theoretical', not 'theoretica', first slide ... Le 26/01/2016 13: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. CECAM workshop "Towards a Common Format for Computational > Materials Science Data" (Saulius Gra?ulis) > 2. Re: CECAM workshop "Towards a Common Format for Computational > Materials Science Data" (Stefaan Cottenier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 26 Jan 2016 09:41:56 +0200 > From: Saulius Gra?ulis <grazulis(a)ibt.lt> > To: tcod(a)lists.crystallography.net > Subject: [TCOD] CECAM workshop "Towards a Common Format for > Computational Materials Science Data" > Message-ID: <56A72344.1090804(a)ibt.lt> > Content-Type: text/plain; charset=utf-8 > > Dear colleagues, > > I am currently at the CECAM workshop "Towards a Common Format for > Computational Materials Science Data", which has direct and very > important relevance to the TCOD and our dictionaries. This afternoon, > I'll give a talk on the TCOD, other crystallographic databases and their > potential for crystallography: > > http://www.crystallography.net/archives/2016/slides/2016-Lausanne-CECAM/sli… > > Yesterday people presented Nomad and MGI databases, a very impressive > development since the last CECAM meeting. > > My main goal would be to make sure that TCOD dictionaries, Nomad and MGI > ontologies are all compatible so that we can seamlessly exchange data > between experimental and theoretical applications. > > All you ideas and comments are very welcome! (and my apologies if I > inadvertently forgot someone in the acknowledgements -- please remind me > ;) ) > > 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

CECAM workshop "Towards a Common Format for Computational Materials Science Data"
by Saulius Gražulis 26 Jan '16

26 Jan '16

Dear colleagues, I am currently at the CECAM workshop "Towards a Common Format for Computational Materials Science Data", which has direct and very important relevance to the TCOD and our dictionaries. This afternoon, I'll give a talk on the TCOD, other crystallographic databases and their potential for crystallography: http://www.crystallography.net/archives/2016/slides/2016-Lausanne-CECAM/sli… Yesterday people presented Nomad and MGI databases, a very impressive development since the last CECAM meeting. My main goal would be to make sure that TCOD dictionaries, Nomad and MGI ontologies are all compatible so that we can seamlessly exchange data between experimental and theoretical applications. All you ideas and comments are very welcome! (and my apologies if I inadvertently forgot someone in the acknowledgements -- please remind me ;) ) Sincerely yours, 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

2 1

Brillouin zone integration tags
by Andrius Merkys 08 May '15

08 May '15

Hi all, after a very interesting discussion with Giovanni Pizzi yesterday I have prepared a list of proposed additions/modifications to the cif_dft.dic concerning the Brillouin zone integration: 1) Redefine tag '_dft_BZ_integration_method' (currently a free text tag) as an enumeration list with values: * 'simple sampling' * 'linear tetrahedron' * 'weighted tetrahedron' (see Blöchl et al. 1994) * 'Monkhorst-Pack' * 'other' (method name given in a new tag '_dft_BZ_integration_method_other_name') Can we list some more widely-used methods? By the way, does 'Monkhorst-Pack' belong here or should better be an option for '_dft_BZ_integration_grid_type' tag? 2) Redefine tags '_dft_BZ_integration_grid_shift_[XYZ]' (free text tags currently) as numeric with value ranges of [0,1). 3) Add a loop to list irreducible BZ points in tags _dft_BZ_integration_grid_IBZ_point_{id,x,y,z,weight}, weights being normalized (0 <= weight <= 1) 4) Add _dft_BZ_integration_smearing_method with following possible values: * 'gaussian' * 'Methfessel-Paxton' * 'Marzari-Vanderbilt' * 'Fermi-Dirac' * 'other' (method name given in new tag '_dft_BZ_integration_smearing_method_other_name') Maybe there are more smearing methods to add? Looking forward for your comments, Andrius Merkys

1 0

NoMaD
by Linas Vilciauskas 02 Apr '15

02 Apr '15

TCOD'ers, Just wanted to draw your attention to the new initiative to store theoretical results: http://nomad-repository.eu/cms/ And the "first use of it": http://journals.aps.org/prl/pdf/10.1103/PhysRevLett.114.105503 -- Linas Vilciauskas

2 1

Re: [TCOD] Questions still left regarding TCOD dictionaries
by Björkman Torbjörn 07 Nov '14

07 Nov '14

Hi Saulius > So, we will have the _conv parameters: > > _dft_basisset_energy_conv > _dft_atom_basisset_energy_conv > _dft_BZ_integration_energy_conv > _dft_cell_energy_conv > _dft_cell_density_conv > _dft_cell_potential_conv > _dft_atom_relax_force_conv > _dft_atom_relax_energy_conv Looking pretty good, but see further below... > (actually, these data names from you e-mail, aren't they?) I think that they were all in the set that I originally wrote down, yes. > These will specify the target values for the energy shifts in the last > (several) cycles). If a structure is deposited to TCOD (and probably > marked as 'converged'), we will assume that the energy shifts were > smaller than these specified values, right? Exactly. I would say that the values should either be either the value actually achieved at the of the relaxation, or the target value given as input to the DFT program, which is an upper bound to the "achieved value" (assuming it was converged). > For example, OQMD made by the Wolverton's group says: " The electronic > ground states were converged to within 0.0001 eV/atom and the crystal > structure to within 0.001 eV/atom." > (http://oqmd.org/documentation/vasp). So I would assume: > > _dft_atom_basisset_energy_conv 0.0001 > _dft_cell_energy_conv 0.001 > > Am I right as for the meaning of the data items and their match with the > published OQMD values? Or should we have yet another data items for these? No, this is not quite correct. Their "electronic ground state convergence" is the accuracy demanded in every single relaxation step, which does not correspond to any of the above mentioned convergence parameters. It is not the basis set. OQMD does not have a basis set convergence procedure that gives a value for _basisset_energy_conv (and I doubt that it can be estimated from the "coarse" and "fine" runs that have been done). Perhaps we should have a value for this though. It would be something like _SCF_conv I guess, since it is the convergence parameter of the self-consistent field cycle. > And then we could have min/median/RMSD/max residual forces on atoms > reported as well. Together, this should give some impression on how good > the calculation has converged, right? Definitely. > We do not need to be "draconic". The same as for COD. For instance, if > the structure was published in a reputable journal, we just accept it, > no mater what the convergence was. If it was good for referees of the > publications, its probably good enough for the database; at least we > need to document the fact of publication. > > For high-throughput projects, personal communications and > pre-publications computations, we can set whatever level we decide, and > this must be more-or-less the "state of the art" level of convergence. > What you realistically can and should achieve. Think that way : would > you publish your own computations with such level of convergence, and > would you trust somebody else's computations with similar parameters? If > you would trust the, than TCOD should accept it. Its community peer > review that should set the rules, like in "normal" publications. > >> Perhaps some two-level system with "hard" acceptance >> criteria and a "warning" level would be good? > > Indeed. We can have three level system; "green" lane are excellent > structures that can be deposited automatically; "yellow" cases (with > warnings as you say) that should receive attention from a specialist -- > we are working on a WordPress based system for this, to be used for COD > but also usable for TCOD; and finally "red" cases that are clearly bad > and should be improved even before taking time of human experts (its a > precious resource, the time!). This sounds great. So peer-reviewed material is accepted (so we'd have to have some journal list?) and non-reviewed material is accepted if quality meets certain criteria. Everything is marked up in some kind of green-yellow-red fashion and so users can easily find out how to treat the numbers. > In this way we should eventually have a trustworthy collection of the > state-of-the art computation results in TCOD. Yes, and as others have pointed out, we do our job to improve the standards in the field. Very good! Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland ________________________________________ Från: Saulius Gražulis [grazulis(a)ibt.lt] Skickat: den 7 november 2014 17:30 Till: Björkman Torbjörn; tcod(a)lists.crystallography.net Ämne: Re: SV: [TCOD] Questions still left regarding TCOD dictionaries Hi, Torbjörn, many thanks for your ideas! On 2014-11-05 18:34, Björkman Torbjörn wrote: > Stefaan supplies good information for everything as usual, so just a > couple of remarks here. Indeed :) I join the thanks! >>> 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, That's the very important point for the dictionary. > 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 proprietary databases... it might > well lead to a lot of trouble. OK. For now we skip energy traces. We can have possibility to record initial state from the open data bases like COD, but it is not obligatory. So we skip it for now. > 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. That's fine. We already specify the corresponding 'method' and 'basisset' data items with references to publications describing them and files with their data. >>>>> 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. > 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. OK, I agree. I skip the detailed energy items for now. Actually, I only included them because they were in the CompChem CML dictionary. >>> 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, OK :) > 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. 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] Questions still left regarding TCOD dictionaries
by Björkman Torbjörn 07 Nov '14

07 Nov '14

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. >>> 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. >>> 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. ... > 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? Best, 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 5 november 2014 15:51 Till: tcod(a)lists.crystallography.net Ämne: Re: [TCOD] Questions still left regarding TCOD dictionaries 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. > 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 -- 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 _______________________________________________ Tcod mailing list Tcod(a)lists.crystallography.net http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod

4 5

Re: [TCOD] Questions still left regarding TCOD dictionaries
by Björkman Torbjörn 07 Nov '14

07 Nov '14

Hi Saulius, > "These data items describe residual forces on atoms in the final > structure. For a converged computation of a stable structure these > should be close to 0. > > A residual force on a given atom should be computed with all other > parameters, including all other atom positions, fixed. The force > components for each atom are given as partial derivatives \d E/\d x, > \d E/\d y and \d E/\d z, where E is the total energy of the system and > x, y, and z are coordinates of the atom for which residual force is > computed (the \d is the partial derivative sign)." > > Is this OK? Or are other definitions used in fact? This looks good and correct. Specifically, the convergence parameter is usually the maximal residual force on any one atom, this is what I think we should demand should be given. Regards, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland

3 2

Questions still left regarding TCOD dictionaries
by Saulius Gražulis 06 Nov '14

06 Nov '14

Hi, folks, I have a (rather long) list of questions regarding the TCOD dictionaries; I've tried to compile it here. I'd be grateful if you comment on them as much as you have time. Questions: 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). We should probably stay of from Hartries, Rydbergs, Bohrs for archiving purposes, shouldn't we? NB.: for archival computer files, it is more convenient to have all data in always in the same units, in all files, and not to allow different units -- at least with current standard software libraries. 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? d) Is my definition of residual forces in cif_tcod.dic, "data_tcod_atom_site_residual_force" correct/acceptable? If not, how should we define them? 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? 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? g) I have attempted to put all DFT related data items into the cif_dft.dic dictionary, and the general computational items (suitable also for MM and other methods), and into the cif_tcod.dic. Are all the parameters in cif_dft.dic indeed DFT specific? Are they named and commented properly? 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? i) "Model" is a very overloaded term. Maybe it would be better to rename _tcod_model to "_tcod_method", or "_tcod_theory_level"? 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? Are localised bases relevant for DFT at all? 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...)? Or are localised bases sets relevant for computing pseudopotentials (cores)? Can I assume that dftxfit, dftorb and dftcfit are plane wave bases? What about 'periodic'? (these terms are all from the Basis Set Exchange database, I guess). k) What is the difference between _dft_atom_basisset and _dft_basisset? Can they be simultaneously used in one computation? If not, maybe we can merge the two definition sets into one? 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? m) Is _dft_cell_energy the same as the "total energy" reported by some codes? Can we rename it to _dft_total_energy? 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? 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)? p) what are other obvious things that one could make wrong in QM/DFT computations, that could be checked formally? Sorry for a long list, but I would like to get the things possibly from the very beginning... Regards, Saulius PS. If you find obvious mistakes in the current dictionaries, please feel free to correct them and commit the corrections back to the repository. -- 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

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Tcod