<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Dear Saulius and TCOD'ers</div><div class="gmail_extra">I'll try to make my comments and suggestions on the original questionnaire. </div><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 1:31 PM, Saulius Gražulis <span dir="ltr"><<a href="mailto:grazulis@ibt.lt" target="_blank">grazulis@ibt.lt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi, folks,<br>
<br>
I have a (rather long) list of questions regarding the TCOD<br>
dictionaries; I've tried to compile it here. I'd be grateful if you<br>
comment on them as much as you have time.<br>
<br>
Questions:<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>). We should probably stay<br>
of from Hartries, Rydbergs, Bohrs for archiving purposes, shouldn't we?<br></blockquote><div><br></div><div>I think eVs are fine. They are more commonly used in the solid state community. Whereas quantum chemists usually give them in Hartree. I think eVs are better since many other people (experimentalists) use them and know what they are. </div><div><br></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>
NB.: for archival computer files, it is more convenient to have all data<br>
in always in the same units, in all files, and not to allow different<br>
units -- at least with current standard software libraries.<br>
<br>
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>
d) Is my definition of residual forces in cif_tcod.dic,<br>
"data_tcod_atom_site_residual_force" correct/acceptable? If not, how<br>
should we define them?<br>
<br>
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>
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>
g) I have attempted to put all DFT related data items into the<br>
cif_dft.dic dictionary, and the general computational items (suitable<br>
also for MM and other methods), and into the cif_tcod.dic. Are all the<br>
parameters in cif_dft.dic indeed DFT specific? Are they named and<br>
commented properly?<br>
<br>
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>
i) "Model" is a very overloaded term. Maybe it would be better to rename<br>
_tcod_model to "_tcod_method", or "_tcod_theory_level"?<br>
<br></blockquote><div><br></div><div>Ok. I introduced this term primarily because I was thinking about PCOD and eventual merging of the two. My scheme was to reserve the _tcod_method for a particular method used to predict the crystal structure (ab initio; without the knowledge of an experimental one) which would be: packing, Monte Carlo annealing, free energy based etc and etc. and reserve _tcod model for a particular model which was used to describe the interactions _dft _forcefield _hf etc. for the final refinement. We could also change it to _theory_level or something. </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">
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? Are<br>
localised bases relevant for DFT at all? 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>
Or are localised bases sets relevant for computing pseudopotentials<br>
(cores)? Can I assume that dftxfit, dftorb and dftcfit are plane wave<br>
bases? What about 'periodic'? (these terms are all from the Basis Set<br>
Exchange database, I guess).<br>
<br>
k) What is the difference between _dft_atom_basisset and _dft_basisset?<br>
Can they be simultaneously used in one computation? If not, maybe we can<br>
merge the two definition sets into one?<br>
<br>
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>
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>
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>
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>
p) what are other obvious things that one could make wrong in QM/DFT<br>
computations, that could be checked formally?<br>
<br>
Sorry for a long list, but I would like to get the things possibly from<br>
the very beginning...<br>
<br>
Regards,<br>
Saulius<br>
<br>
PS. If you find obvious mistakes in the current dictionaries, please<br>
feel free to correct them and commit the corrections back to the repository.<br>
<br>
--<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>
_______________________________________________<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>
</blockquote></div><div class="gmail_extra"><br></div>I'll follow up on the other questions later.</div><div class="gmail_extra"><br>Regards,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Linas<br clear="all"><div><br></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>