[Cod-bugs] depositing "duplicates"

Tue Jun 22 13:50:35 EEST 2021

Dear Erik,

I will provide a combined answer from Saulius and me to your last letter.

On 2021-06-22 10:50, Rakovský Erik wrote:

Dear Saulius, dear Antanas,
> and what about using
> _cod_suboptimal_structure        no
> as a switch for resetting status of older structures to suboptimal?
>

This would not work. The current implementation of the system is only
capable
of recognising files that are being deposited as suboptimal and does not
check the previously deposited files.

(of course I started from the "routine" structure and that best one was
> last to deposit 😄)

Makes perfect sense. Steps to resolve this situation:

   1. Add the following two lines to the rest of the CIF files and deposit
   them:

   _cod_related_optimal_entry_code  3000306
   _cod_suboptimal_structure        yes

   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.

   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.

   2. 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
   from "yes" to "no". Alternatively, you can also remove the
   _cod_suboptimal_structure data item
   altogether since "no is the default value.
   3. Using the COD website interface update the suboptimal entry 3000306
   by adding the following two lines:

   _cod_related_optimal_entry_code  3000309
   _cod_suboptimal_structure        yes

   4. 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".

However, thanks a lot, I am going to play with it.
>
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:

   1. You send us the CIFs and we use the "human override" feature to
   insert your structures into the COD;
   2. 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.

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:

   - _computing.structure_refinement
   - _computing.structure_solution

Please let us know if you were able to successfully deposit your structures.

Sincerely,
Antanas

On Tue, 22 Jun 2021 at 10:40, Saulius Gražulis <grazulis at ibt.lt> wrote:

> 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
> No AFIX
> 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.
>
> Sincerely,
> Saulius
>
> --
> 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
>
> _______________________________________________
> Cod-bugs mailing list
> Cod-bugs at lists.crystallography.net
> http://lists.crystallography.net/cgi-bin/mailman/listinfo/cod-bugs
>

-- 
Antanas Vaitkus,
PhD student at Vilnius University Institute of Biotechnology,
room V325, Saulėtekio al. 7,
LT-10257 Vilnius, Lithuania

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crystallography.net/pipermail/cod-bugs/attachments/20210622/7dd5481c/attachment.htm>