<div dir="ltr"><div>Dear Erik,<br><br></div>I will provide a combined answer from Saulius and me to your last letter.<br><div class="gmail-moz-cite-prefix"><br>
</div>
<div class="gmail-moz-cite-prefix">On 2021-06-22 10:50, Rakovský Erik
wrote:</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
Saulius, dear Antanas, <br>
and what about using<br>
_cod_suboptimal_structure no<br>
as a switch for resetting status of older structures to
suboptimal?<br></blockquote><div><br></div><div>This would not work. The current implementation of the system is only capable<br></div><div>of recognising files that are being deposited as suboptimal and does not<br></div><div>check the previously deposited files.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(of course I started from the "routine" structure and that best one was last to deposit
<span id="gmail-😄">😄</span>)</blockquote><div><br></div><div>Makes perfect sense. Steps to resolve this situation:<br></div><ol><li>Add the following two lines to the rest of the CIF files and deposit them:<br><br>_cod_related_optimal_entry_code 3000306<br> _cod_suboptimal_structure yes<br><br>Upon successful deposition the CIF files will most likely be assigned sequential COD IDs 3000307, 3000308, 3000309. Let's assume that entry 3000309 is the optimal one.<br><br>Steps 2-4 detail how to properly markup the optimal-suboptimal relations. You can either do that by following the provided instructions or let us know which structure is the optimal one and we can change the markup on our end.<br><br></li><li>Using the COD website interface update the optimal entry 3000309 by removing the _cod_related_optimal_entry_code data item and by changing the _cod_suboptimal_structure<br>from "yes" to "no". Alternatively, you can also remove the _cod_suboptimal_structure data item<br>altogether since "no is the default value.</li><li>Using the COD website interface update the suboptimal entry 3000306 by adding the following two lines:<br><br>_cod_related_optimal_entry_code 3000309<br> _cod_suboptimal_structure yes<br><br></li><li>Using the COD website interface update the suboptimal entries 3000307, 3000308 by changing the _cod_related_optimal_entry_code data item value from "3000306" to "3000309".</li></ol><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>However,
thanks a lot, I am going to play with it.</div></blockquote><div><p>We are now discussing a mechanism for how you could mark the
structures as being solved by different techniques and thus not
duplicates; but it will take us some time to roll out this
feature. I have tested the optimal-suboptimal markup solution on a test server and it seems to work, however, if it does fail for you for some reason there are two other options:<br></p><ol><li>You send us the CIFs and we use the "human override" feature to
insert your structures into the COD;
</li><li>At the moment, you can use "_sample_thermal_history" or
"_sample_pressure_history" tags to specify your refinement method;
these data names are of course not meant for refinement
peculiarities, but for describing samples that were
quenched/annealed/pressurised; but if you would prefer to deposit
the structure into the COD yourself, this would be currently a
workaround.</li></ol>
<p>After the structures are deposited and the COD IDs are assigned,
you or we can edit the files and rename the
'_sample_{pressure|thermal}_history' to something more
appropriate. I see two data names in the CIF core dictionary that
seem to be designed for your purposes:</p></div><div> <ul><li>_computing.structure_refinement<br>
</li><li>_computing.structure_solution</li></ul><div>Please let us know if you were able to successfully deposit your structures.<br><br></div><div>Sincerely,<br></div><div>Antanas<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Jun 2021 at 10:40, Saulius Gražulis <<a href="mailto:grazulis@ibt.lt">grazulis@ibt.lt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Hello, Erik,</div>
<div>dear CODers,</div>
<div><br>
</div>
<div>As Antanas has mentioned, the '_cod_related_optimal_entry_code'
and '_cod_suboptimal_structure' data items are essential for
marking different versions of the structure refinement, in case
you demonstrate that one structure solution or refinement method
is better than all others.<br>
</div>
<div><br>
</div>
<div>On 2021-06-21 19:47, Rakovský Erik
wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">so my problem in short is
that I need to have deposited 4 structures of the same compound
and the same polymorph but refined using several strategies. The
results/differences will be thoroughly discussed in the article.<br>
For example<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<ul>
<li><span>"routine" refinement with geometrically placed
hydrogens, X-H distances fixed in default distances,
Uiso(H) riding (1.2 or 1.5 times Ueq of parent atom)</span></li>
<li><span>the same strategy but X-H distances free to refine
and even Uisos can be sometimes refined freely, too</span></li>
<li><span>Hirshfeld atom refinement using several methods
(HF/DFT, various basis sets or functionals) - in my case,
I used two different basis sets for final two refinements</span></li>
</ul>
</div>
</blockquote>
<p>This is a very valuable information. <br>
</p>
<p>The problem may be that if the unit cells of all structures are
very similar or identical, and you deposit the structures
subsequently, the system will complain about duplicates.</p>
<p>Upon original deposition, however, you can concatenate all
structures into one CIF file and submit the file. The file will be
split on the server side, and all structures will be deposited
even if they are very similar – duplicates are not searched among
the "fledgings from the same nest", i.e. structures originating
from the same deposition.</p>
<p>In the worst case, if the deposition of similar structures does
not work over the net, please e-mail the structures to me or
Antanas, and we will insert them directly into the Subversion repo
(under you name, of course :).<br>
</p>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<div>originally I described the refinement using <br>
</div>
<div><br>
</div>
<div>_olex2_refinement_description
<div>;</div>
<div>HAR refinement using NoSpherA2/ORCA</div>
<div>def2-TZVPP basis set</div>
<div>PBE0 functional</div>
<div>integration accuracy Max</div>
<div>No AFIX</div>
<div>SCF Threshold VeryTightSCF</div>
<div>SCF Strategy VerySlowConv</div>
<span>;<br>
</span></div>
</div>
</blockquote>
<p>This data item is useful, for sure, and can/should be retained.
Our system will not recognise it, most probably, but it should not
prevent the structure from being deposited.</p>
<p>Hope this helps.</p>
<p>Sincerely,<br>
Saulius<br>
</p>
<pre cols="72">--
Dr. Saulius Gražulis
Vilnius University, Life Science Center, Institute of Biotechnology
Saulėtekio al. 7, LT-10257 Vilnius, Lietuva (Lithuania)
phone (office): (+370-5)-2234353, mobile: (+370-684)-49802, (+370-614)-36366
</pre>
</div>
_______________________________________________<br>
Cod-bugs mailing list<br>
<a href="mailto:Cod-bugs@lists.crystallography.net" target="_blank">Cod-bugs@lists.crystallography.net</a><br>
<a href="http://lists.crystallography.net/cgi-bin/mailman/listinfo/cod-bugs" rel="noreferrer" target="_blank">http://lists.crystallography.net/cgi-bin/mailman/listinfo/cod-bugs</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div>Antanas Vaitkus,<br></div>PhD student at Vilnius University Institute of Biotechnology,<br><span><span><span>room V325, </span></span></span>Saulėtekio al. 7,<br>LT-10257 Vilnius, Lithuania<br></div><div><div><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><br></div></div></div></div></div></div></div></div></div></div></div>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.