[Cod-bugs] depositing "duplicates"

Saulius Gražulis grazulis at ibt.lt
Tue Jun 22 10:40:25 EEST 2021

Hello, Erik,
dear CODers,

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.

On 2021-06-21 19:47, Rakovský Erik wrote:
> 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.
> For example
>   * "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)
>   * the same strategy but X-H distances free to refine and even Uisos
>     can be sometimes refined freely, too
>   * 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
This is a very valuable information.

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.

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.

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 :).

> originally I described the refinement using
> _olex2_refinement_description
> ;
> HAR refinement using NoSpherA2/ORCA
> def2-TZVPP basis set
> PBE0 functional
> integration accuracy Max
> SCF Threshold VeryTightSCF
> SCF Strategy VerySlowConv
> ;

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.

Hope this helps.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20210622/de2567c8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: grazulis.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20210622/de2567c8/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20210622/de2567c8/attachment-0001.sig>

More information about the Cod-bugs mailing list