<div dir="ltr"><div class="gmail_extra">Dear Saulius and TCOD'ers<br><br>One of the first questions for me when looking at the new dictionary was the <span style="color:rgb(0,0,0);white-space:pre-wrap">_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 "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-ground-state" and "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-excited-state". But honestly have no idea what does the "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">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 experimentalists mean as a metastable structure could be a nice local minimum (same as "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-ground-state")</span><span style="color:rgb(0,0,0);white-space:pre-wrap"> 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. </span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap">My underline is that in DFT there is nothing like life-time... </span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap">I'm also not entirely sure what is the difference between the "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-soft-phonon" and "</span><span style="color:rgb(0,0,0);white-space:pre-wrap">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? </span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><font color="#000000"><span style="white-space:pre-wrap">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: </span></font><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-metastable, </span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-soft-phonon, </span><span style="color:rgb(0,0,0);white-space:pre-wrap">crystal-transition-state, </span><span style="color:rgb(0,0,0);white-space:pre-wrap">vacuum-ground-state, </span><span style="color:rgb(0,0,0);white-space:pre-wrap">vacuum-excited-state, </span><span style="color:rgb(0,0,0);white-space:pre-wrap">vacuum-metastable,</span><span style="color:rgb(0,0,0);white-space:pre-wrap"> vacuum-transition-state completely. </span></div><div class="gmail_extra"><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div class="gmail_extra"><font color="#000000"><span style="white-space:pre-wrap">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).</span></font></div><div class="gmail_extra"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div class="gmail_extra"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 5, 2014 at 11:34 AM, Björkman Torbjörn <span dir="ltr"><<a href="mailto:torbjorn.bjorkman@aalto.fi" target="_blank">torbjorn.bjorkman@aalto.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear all,<br>
<br>
Stefaan supplies good information for everything as usual, so just a couple of remarks here.<br>
<span class=""><br>
>>> f) If e) is "yes", then we can talk about "microcycles" (electron w/f<br>
>>> refinement) and "macrocycles" (nuclei/cell shifted in each<br>
>>> "macrocycle"). We could also document total energy changes in all these<br>
>>> cycles, to monitor the convergence, as I suggest in<br>
>>> _tcod_computation_cycle_... data items. Is such view acceptable? What is<br>
>>> the terminology used in different codes? Will such table be useful? Will<br>
>>> it be easy to obtain from most codes?<br>
>><br>
>> I advice to stay away from that. Your view is correct, but this<br>
>> information is often not mentioned even in papers. Documenting such<br>
>> changes would be arbitrary, to some extent. The final relaxed geometry<br>
>> is well-defined, but what do you take as the unrelaxed starting point...?<br>
><br>
</span><span class="">> The idea is that the unrelaxed structure starts somewhere at high<br>
> energies, and then it converges to low energy that no longer changes<br>
> significantly with refinement cycles. For me, this would be evidence<br>
> that the process has converged. I guess when one does a calculation, one<br>
> looks into such energy behavior traces, doesn't one?<br>
><br>
> If so, then it makes sense to have tools to record the traces in CIFs,<br>
> as an evidence of convergence and convergence checks.<br>
><br>
> I also want to point out that the presence of the data items (for energy<br>
> tables) in the dictionary does not imply any obligation to use them. Any<br>
> CIF will be correct and valid without them. Its just if we decide to<br>
> include them, there will be a publicly announced way to do this.<br>
<br>
</span>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.<br></blockquote><div><br></div>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...</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
>>> Is it enough for DFT to specify<br>
>>> just an energy cut-off, assuming plane wave bases (for a given<br>
>>> pseudopotential), or are there different possible bases also among plane<br>
>>> waves (I guess there should not be, but maybe I'm missing something...)?<br>
>><br>
>> For plane waves the energy cut-off is the only quantity. But there are<br>
>> many other types of basis sets that are no plane waves. For these, more<br>
>> specification might be needed (although often they are contained in the<br>
>> published definition of the basis set).<br>
><br>
</span><span class="">> I see. OK, I so understand that DFT can work both with PW and localized<br>
> bases, and the exact basis should be specified in the input file (and<br>
> might be documented in the CIF).<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
<br>
>>> n) Am I correct to assume that the "total energy" reported by codes will<br>
>>> always be the sum of separate energy terms (Coulomb, exchange,<br>
>>> 1-electron, 2-electron, etc.)? Is there an interest to have them<br>
>>> recorded in the result data files (CIFs) separately? If yes, what is the<br>
>>> "Hartree energy" (is it a sum of all single electron energies in the SCF<br>
>>> for each of them?), "Ewald energy" (is it the electrostatic lattice<br>
>>> energy, obtained by Ewald summation?) and the rest in the values from<br>
>>> the AbInit output file? Are these terms consistent across QM codes?<br>
>><br>
>> Also here I think this is asking for way too much detail. Most codes can<br>
>> indeed split up the total energy in many contributions, but papers<br>
>> usually do not report that (only in the special cases when there is<br>
>> useful information in the splitting). If papers don't do it, databases<br>
>> shouldn't either -- that feels as a sound criterium.<br>
><br>
</span><span class="">> Interesting idea. Well, that makes our life easier.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>Completely agree. Different terms can be evaluated using different methods so the comparison many cases will not make sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
...<br>
<span class="">> May I disagree to some extent. If we can do better checks than journals<br>
> do, why shouldn't we? That would be a useful tool, a help for journal<br>
> reviewers, and one possible way to improved the situation.<br>
</span>...<br>
<span class="">> In short, I think that it would be quite useful to have uniform *actual*<br>
> convergence criteria in the CIF output, and check them before inserting<br>
> computations into TCOD, like we check crystal structure symmetry, bond<br>
> distances, parameter shifts or R-factors.<br>
<br>
</span>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?<br></blockquote><div><br></div><div>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...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<span class=""><br>
Hi, Stefaan,<br>
<br>
many thanks for your quick and very informative answer. I'll adjust the<br>
dictionaries according to it. Below are some of my comments.<br>
<br>
On 2014-11-05 13:33, Stefaan Cottenier wrote:<br>
</span><span class="">> Let me comment on those questions that I can do on the spot, without<br>
> looking into the dictionary yet :<br>
><br>
>> a) the units of energy that we started to use in the dictionaries are eV<br>
>> (electron-Volts). For distances, we should probably use Angstroems,<br>
>> since then we can easier compare computation results with<br>
>> crystallographic experimental data. This naturally suggests units for<br>
>> forces as eV/A. Is that OK, or should we better use SI units of similar<br>
>> scale (say aJ -- atto-Joules, on the similar scale)? The only problem I<br>
>> see with eV is that it is measured, not defined from the basic SI units<br>
>> (<a href="http://en.wikipedia.org/wiki/Electronvolt" target="_blank">http://en.wikipedia.org/wiki/Electronvolt</a>,<br>
>> <a href="http://physics.nist.gov/cuu/Units/outside.html" target="_blank">http://physics.nist.gov/cuu/Units/outside.html</a>).<br>
<br>
</span><span class="">> Although SI units would be in principle the good choice, nobody uses<br>
> them in this context. At least eV and Angstrom have a special status<br>
> ('tolerated units' within SI), hence allowing eV, Angstrom and therefore<br>
> eV/A for forces is a fair compromise.<br>
<br>
</span><span class="">Good. So we stay with eV and A, with eV/A for forces, as already<br>
documented in our dictionaries.<br>
<br>
</span><span class="">>> b) Is nuclear electric dipole moment used/necessary for DFT computations<br>
>> (_dft_atom_type_nuclear_dipole)?<br>
>><br>
>> c) If b) is "yes", what units we should use for electric dipole (and<br>
>> higher moments) -- Debayes, e*A (amount of unit charges times<br>
>> Angstroems), or something else?<br>
><br>
> There must be some kind of confusion here -- my old nuclear physics<br>
> courses always emphasized that nuclei do not have an electric dipole<br>
> moment. Either you mean magnetic dipole moment or nuclear quadrupole<br>
> moment? Anyway, nuclear properties are never required for DFT<br>
> calculations as such, but they can be used to convert DFT-predictions<br>
> into quantities that are experimentally accessible. I don't see the need<br>
> to keep track of this, however, in a computational database.<br>
<br>
</span><span class="">OK, this is a gap in my education -- I must have overlooked the zero<br>
nuclear electric dipole during my university years...<br>
<br>
Setting aside the theoretical question whether the quarks can move in<br>
such a way as to give non-zero dipole, I remove the<br>
_dft_atom_type_nuclear_dipole as lacking theoretical justification and<br>
empirical evidence. For magnetic dipole, a<br>
_dft_atom_type_magn_nuclear_moment could be introduced if needed (for<br>
orbital and spin magnetic moments the data names are already there).<br>
<br>
</span><span class="">>> e) If I understand correctly, DFT and most other QM methods operate<br>
>> under Born-Oppenheimer approximation; under this approximation, electron<br>
>> densities (electron wave-functions) are optimised to minimal energy at<br>
>> fixed nuclei and unit cell parameters, and when this converges, the<br>
>> nuclei parameters and/or cell constants are changed slightly (e.g. along<br>
>> gradients), and the electron energy is minimised again. Is this a<br>
>> correct view? Is it a universal situation across QM codes?<br>
><br>
> Yes, correct. It is pretty universal. There some special-purpose<br>
> applications that do not make the born-oppenheimer approximation, but<br>
> that's really a minority.<br>
<br>
</span>OK. Thanks for confirmation.<br>
<span class=""><br>
>> f) If e) is "yes", then we can talk about "microcycles" (electron w/f<br>
>> refinement) and "macrocycles" (nuclei/cell shifted in each<br>
>> "macrocycle"). We could also document total energy changes in all these<br>
>> cycles, to monitor the convergence, as I suggest in<br>
>> _tcod_computation_cycle_... data items. Is such view acceptable? What is<br>
>> the terminology used in different codes? Will such table be useful? Will<br>
>> it be easy to obtain from most codes?<br>
><br>
> I advice to stay away from that. Your view is correct, but this<br>
> information is often not mentioned even in papers. Documenting such<br>
> changes would be arbitrary, to some extent. The final relaxed geometry<br>
> is well-defined, but what do you take as the unrelaxed starting point...?<br>
<br>
</span><span class="">The idea is that the unrelaxed structure starts somewhere at high<br>
energies, and then it converges to low energy that no longer changes<br>
significantly with refinement cycles. For me, this would be evidence<br>
that the process has converged. I guess when one does a calculation, one<br>
looks into such energy behavior traces, doesn't one?<br>
<br>
If so, then it makes sense to have tools to record the traces in CIFs,<br>
as an evidence of convergence and convergence checks.<br>
<br>
I also want to point out that the presence of the data items (for energy<br>
tables) in the dictionary does not imply any obligation to use them. Any<br>
CIF will be correct and valid without them. Its just if we decide to<br>
include them, there will be a publicly announced way to do this.<br>
<br>
</span><span class="">>> h) The CML CompChem dictionary mentions SCF as a method. I know HF and<br>
>> its modifications are SCF; is DFT technically also SCF? Are there more<br>
>> SCF methods that are not HF? Should we include "SCF" into the<br>
>> enumeration values of the _tcod_model as a separate model?<br>
><br>
> 'SCF' refers only to the fact that a particular iterative solving scheme<br>
> is used. As such, I would consider that term as being less informative<br>
> than HF or DFT (one could even imagine to do DFT without SCF, although<br>
> in practice this very rarely is done).<br>
<br>
</span><span class="">OK; so we skip SCF as a separate "model".<br>
<br>
</span><span class="">>> j) I have taken the _dft_basisset_type list from<br>
>> <a href="http://www.xml-cml.org/dictionary/compchem/#basisSet" target="_blank">http://www.xml-cml.org/dictionary/compchem/#basisSet</a>, to strive at least<br>
>> potentially for a possibility of the CIF->CML->CIF roundtrip. The two<br>
>> big classes of basis functions, as I have learned, are localised<br>
>> (Slater, Gaussian) and plane wave. Should we introduce such<br>
>> classification on top of the _dft_basisset_type enumerator?<br>
><br>
> I don't think so. It will be implicit in the name people use for the<br>
> basis set.<br>
<br>
</span><span class="">OK. The type of the basis set should be implied from the basis set date<br>
(name, files, reference).<br>
<br>
</span><span class="">>> Are<br>
>> localised bases relevant for DFT at all?<br>
><br>
> Yes, sure (SIESTA, for instance).<br>
<br>
</span><span class="">Good to know. Thanks for the info!<br>
<br>
</span><span class="">>> Is it enough for DFT to specify<br>
>> just an energy cut-off, assuming plane wave bases (for a given<br>
>> pseudopotential), or are there different possible bases also among plane<br>
>> waves (I guess there should not be, but maybe I'm missing something...)?<br>
><br>
> For plane waves the energy cut-off is the only quantity. But there are<br>
> many other types of basis sets that are no plane waves. For these, more<br>
> specification might be needed (although often they are contained in the<br>
> published definition of the basis set).<br>
<br>
</span><span class="">I see. OK, I so understand that DFT can work both with PW and localized<br>
bases, and the exact basis should be specified in the input file (and<br>
might be documented in the CIF).<br>
<br>
</span><span class="">>> l) There are a lot of *_conv data items declared (e.g.<br>
>> _dft_basisset_energy_conv). Are they for convergence tests? Or for<br>
>> convolutions? What is their proposed definition?<br>
><br>
> These are the convergence criteria, for instance: stop the iterative<br>
> (SCF) cycle once the total energy does change by less than<br>
> _dft_basisset_energy_conv during the last few iterations.<br>
<br>
</span><span class="">Perfect. Now, are these the *desired* criteria, or the *obtained* values<br>
(i.e. actual values of the computation)? Although probably we can assume<br>
that in any case the energy change at the end of the computation was<br>
less than the specified _dft_basisset_energy_conv value, and the same<br>
for other *_conv values, right?<br>
<br>
I'll add units and explanations to the dictionary.<br>
<br>
</span><span class="">>> m) Is _dft_cell_energy the same as the "total energy" reported by some<br>
>> codes? Can we rename it to _dft_total_energy?<br>
><br>
> Probably yes.<br>
<br>
</span><span class="">Hmmm... We need some explanation in the dictionary how these values are<br>
supposed to be used.<br>
<br>
</span><span class="">>> n) Am I correct to assume that the "total energy" reported by codes will<br>
>> always be the sum of separate energy terms (Coulomb, exchange,<br>
>> 1-electron, 2-electron, etc.)? Is there an interest to have them<br>
>> recorded in the result data files (CIFs) separately? If yes, what is the<br>
>> "Hartree energy" (is it a sum of all single electron energies in the SCF<br>
>> for each of them?), "Ewald energy" (is it the electrostatic lattice<br>
>> energy, obtained by Ewald summation?) and the rest in the values from<br>
>> the AbInit output file? Are these terms consistent across QM codes?<br>
><br>
> Also here I think this is asking for way too much detail. Most codes can<br>
> indeed split up the total energy in many contributions, but papers<br>
> usually do not report that (only in the special cases when there is<br>
> useful information in the splitting). If papers don't do it, databases<br>
> shouldn't either -- that feels as a sound criterium.<br>
<br>
</span><span class="">Interesting idea. Well, that makes our life easier.<br>
<br>
On the other hand, electronic media, like database, can record and make<br>
usable more information than a traditional paper or PDF publication. We<br>
should not overlook such possibilities and use them when needed.<br>
<br>
For example, in protein crystallography, structure factors were not<br>
reported in publications at the very beginning, due to a sheer volume of<br>
data (a protein crystal can give you a million of unique reflections);<br>
but today it is a must and a self-evident thing to deposit such data<br>
electronically into PDB.<br>
<br>
</span><span class="">>> o) How does one check that computation has converged on k-points,<br>
>> E-cuttof, smear and other parameters, and that pseudopotential is<br>
>> selected right? From the Abinit tutorial<br>
>> (<a href="http://flex.phys.tohoku.ac.jp/texi/abinit/Tutorial/lesson_4.html" target="_blank">http://flex.phys.tohoku.ac.jp/texi/abinit/Tutorial/lesson_4.html</a>) I got<br>
>> impression that one needs to run computation with different values of<br>
>> these parameters, and see that the total energy, or other gauge values,<br>
>> no longer change significantly when these parameters are increased. Is<br>
>> that right? If yes, are there codes that do this automatically? Should<br>
>> we require Etotal (or coordinates') dependence on k-grid, E-cuttof,<br>
>> smear, to check convergence when depositing to TCOD? Or should TCOD side<br>
>> check this automatically when appropriate (say for F/LOSS codes)?<br>
><br>
> "k-points, E-cuttof, smear and other parameters" are indeed tested as<br>
> you describe.<br>
<br>
</span><span class="">OK. Thanks for clarification.<br>
<br>
I think it would be beneficial to have such checks included into teh<br>
results file...<br>
<br>
</span>> ... The pseudpotential can't be tested that way, what people<br>
<span class="im">> usually do is to verify whether the numerically converged results when<br>
> using a particular pseudo do agree with experiment.<br>
<br>
</span><span class="im">I see. OK, we'll have to trust PP was selected properly.<br>
<br>
Actually, TCOD + COD can check the computations against empirical<br>
(crystallographic) data -- say interatomic distances, bonds, angles,<br>
coordination sphere geometry, etc. The results might be interesting --<br>
significant discrepancies will either predict unseen new phenomena or<br>
point out at problems that can be fixed readily.<br></span></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im">
<br>
</span><span class="im">> Doing such tests is the responsibility of each user. In principle,<br>
> journals should not publish ab initio results if such tests are missing.<br>
> Journals are not that strict, unfortunately. And some researchers are<br>
> not very careful in that respect.<br>
><br>
> It's a longstanding problem, that is gradually being solved because<br>
> computers are so fast now that the default settings of most codes are<br>
> sufficiently accurate for many cases, even if a researcher does not<br>
> explicitly tests it.<br>
><br>
> Also here, TCOD shouldn't try to do better than the journals do.<br>
<br>
</span><span class="im">May I disagree to some extent. If we can do better checks than journals<br>
do, why shouldn't we? That would be a useful tool, a help for journal<br>
reviewers, and one possible way to improved the situation.<br>
<br>
In crystallography, the situation is sometimes similar. IUCr journals<br>
are very good at checking structures, but some chemical journals, even<br>
the "high profile" ones, give you CIFs that may even have syntax errors<br>
in them! For me, this hints that nobody bothered to look at the data<br>
before publication. But how can the claim then that he paper was "peer<br>
reviewed"? The text apparently was, but the data probably not. This is<br>
not a good way in today's data-driven sciences.<br>
<br>
COD does checks, and we plan more -- and it helps e.g. when personal<br>
communications or prepublication structures are deposited. My personal<br>
experience was very positive on this -- the first personal communication<br>
I tried to send to COD was marked as not converged properly; indeed this<br>
was an oversight, and a couple more refinement cycles fixed the problem.<br>
<br>
I fund such checks to be a very useful tool, so why not having something<br>
similar for TCOD? Especially, when we expect a large number of<br>
structures from wide-scale computational projects, where not every<br>
computation is checked manually.<br>
<br>
</span><span class="im">>> p) what are other obvious things that one could make wrong in QM/DFT<br>
>> computations, that could be checked formally?<br>
><br>
> That's an interesting one... With no answer from my side. If there is<br>
> anything that can go obviously wrong, the codes will have an internal<br>
> test for it already.<br>
<br>
</span><span class="im">Well, an obviously wrong thing would be insufficient checks for<br>
convergence (to coarse k-grid, to little steps of minimization, etc.).<br>
<br>
Usually, experienced computational chemists will check for these, but<br>
ever so often a MSc student who is just starting to learn things will<br>
compute a structure, and the experienced boss will happen to be in the<br>
conference... The structure may look reasonable, especially for an<br>
unexperienced eye, but in fact it may be inaccurate... You know what I<br>
mean :)<br>
<br>
In short, I think that it would be quite useful to have uniform *actual*<br>
convergence criteria in the CIF output, and check them before inserting<br>
computations into TCOD, like we check crystal structure symmetry, bond<br>
distances, parameter shifts or R-factors.<br>
<br>
The question is, what should be the universal criteria for QChem?<br>
<br>
Regards,<br>
Saulius<br>
<br>
</span><span class="im">--<br>
Saulius Gražulis<br>
<br>
Biotechnologijos institutas<br>
Graičiūno 8<br>
02241 Vilnius-28<br>
Lietuva<br>
<br>
Tel.: vidaus BTI:    226<br>
      Vilniaus BTI:  (8-5)-260-25-56<br>
      mobilus TELE2: (8-684)-49-802<br>
      mobilus OMNIT: (8-614)-36-366<br>
<br>
</span><div class=""><div class="im">_______________________________________________<br>
Tcod mailing list<br>
<a href="mailto:Tcod@lists.crystallography.net">Tcod@lists.crystallography.net</a><br>
<a href="http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod" target="_blank">http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod</a><br>
<br>
_______________________________________________<br>
Tcod mailing list<br>
<a href="mailto:Tcod@lists.crystallography.net">Tcod@lists.crystallography.net</a><br>
<a href="http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod" target="_blank">http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod</a><br>
</div></div></blockquote></div><br><br clear="all"><div>Best,</div><div><br></div><div>Linas</div>-- <br><div class="gmail_signature"><div dir="ltr">Linas Vilciauskas<br>Postdoctoral Research Fellow<br>Dept. of Chemistry<br>New York University<br>100 Washington Square East / 830BB<br>New York, NY 10003<br><a href="mailto:linas.vilciauskas@nyu.edu" target="_blank">linas.vilciauskas@nyu.edu</a><br>Phone:  +1-347-614-6831</div></div>
</div></div>