<div dir="ltr"><div class="gmail_extra">Dear Saulius,</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 3:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2013-09-06 19:02, Stefaan Cottenier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(9) Which kind of computed structures will TCOD accept? Ground state<br>
structures, obviously? Metastable structures probably as well? Also if<br>
they are not dynamically stable (soft phonon mode)? (that is not<br>
routinely examined) And what about transition state structures? (never<br>
observable in experiment, yet very useful to know -- and hard to find --<br>
in order to understand reactions) If the latter are allowed, then they<br>
should be tagged as such.<br>
</blockquote>
<br>
I find this suggestion very good and comprehensive. I have added the '_tcode_structure_type' data name to cif_tcod.dic based on this suggestion. I would be grateful if you verify that I did not put too much nonsense into the definitions, my understanding if the metastable/transition/soft phonon structures is so far rather limited... The dictionary is in its usual place: <a href="http://www.crystallography.net/tcod/cif/dictionaries/cif_tcod.dic" target="_blank">http://www.crystallography.<u></u>net/tcod/cif/dictionaries/cif_<u></u>tcod.dic</a> (Subversion repo: svn://<a href="http://cod.ibt.lt/tcod/cif/dictionaries/" target="_blank">cod.ibt.lt/tcod/cif/<u></u>dictionaries/</a>)<br>
<br></blockquote><div> </div><div>But would it not becoming, reaction and not crystallographic database? Having a phonon spectrum, even if there are imaginary modes is probably very useful, some materials only become stable due to anharmonicity, so their phonon spectra always contain some imaginary modes. But storing transition state structures would be an enormous overhead... Moreover, if one wants to store TS one should also store the reactant and product states as well. Then all the definitions of the method on how that TS was obtained... Would one store all the intermediate NEB images then?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One more related question:<br>
<br>
If I understand correctly, from what I recall from the QM lectures, we can have in principle two kinds of boundary conditions for localised particle wave functions:<br>
<br>
a) vanishing at the infinity (modelling single molecule in vacuum), and<br>
b) periodic (modelling an ideal crystal).<br></blockquote><div><br></div><div>That's is kind of correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>From what I have read in manuals of the QM codes, most implement b), and a) is approximated by putting a molecule in a large enough "unit cell" so that interactions between molecule images are negligible.<br></blockquote>
<div><br></div><div>This schism results from the fact that there are two main approaches to the basis sets used to expand the wave-functions in electronic structure codes. Plane-wave are very popular in the solid-state community and due to their inherent periodicity are very suitable for dealing with periodic systems (solids > surfaces > infinite wires). Atomic basis sets such as Gaussian-type orbitals are very popular in the molecule calculations or non-periodic systems. PW are rarely used for doing molecule calculations, since you need a big box so that the molecules would not interact, or you have to decouple them, by e.g. setting the potential to zero at the cell boundaries and self-consistently solving that problem. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is this a correct view? Does any code implement (a) as a separate mode of computation?<br>
<br>
In either case, we should probably have a special tag that distinguishes "true" crystal structures from the "convenience" unit cells that are non-physical but are set up solely to solve a molecule structure problem with the same code that also deals with crystals. Any ideas how to tell from the computations which mode was used?<br>
</blockquote><div><br></div><div>We should be only interested in periodic structures. Or I would be even more strict - 3D periodic (crystals). We should not worry about the molecules or clusters... or leave it to others :-) We just should not have any limitation on the supercell size of the structure, but in general it should be strictly 3D periodic for this database. That would make life much easier and give the database some shape on what we are trying to systematize. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Saulius<br></blockquote><div><br></div><div>Best regards,</div><div><br></div><div>Linas </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
______________________________<u></u>_________________<br>
Tcod mailing list<br>
<a href="mailto:Tcod@lists.crystallography.net" target="_blank">Tcod@lists.crystallography.net</a><br>
<a href="http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod" target="_blank">http://lists.crystallography.<u></u>net/cgi-bin/mailman/listinfo/<u></u>tcod</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><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>