Re: enumeration values

You will notice that the definition of _atom_site_refinement_flags starts with the sentence 'This definition has been superceded and is retained here only for archival purposes.'� The reason for retiring this item is exactly the problem raised here.� An enumeration list of all possible combinations of the seven flags would be fearsome, so the item was split into _posn, _occupancy and _adp, which allows three flags to be specified and all combintation of these.� Therefore forget about the first item quoted in the email.� It no longer exists.� This may cause some early CIFs t0 register errors, but this is likely not to be the only source of error as we tended to be rather lenient in our acceptance of mildly non-conforming CIFs in the early days.� I believe Acta Cryst. is working on a program to check the archive for conformance and correct where necessary.

David Brown
Chair of the core CIF Dictionary Maintenance Group.




Richard Gildea wrote:

Dear All,

The enumeration entry in cif_core.dic for�_atom_site_refinement_flags is as follows:

loop_ _enumeration

_enumeration_detail . 'no refinement constraints'

                               S 'special-position constraint on site'
                               G 'rigid-group refinement of site'
                               R 'riding-atom site attached to non-riding atom'
                               D 'distance or angle restraint on site'
                               T 'thermal displacement constraints'
                               U 'Uiso or Uij restraint (rigid bond)'
                               P 'partial occupancy constraint'

No combinations are specified explicitly as being allowed, which is in contrast to the entry for�_atom_site_refinement_flags_posn:

loop_ _enumeration

_enumeration_detail

                     . 'no constraints on  positional coordinates'
                     D 'distance or angle restraint on positional coordinates'
                     G 'rigid-group refinement of positional coordinates'
                     R 'riding-atom site attached to non-riding atom'
                     S 'special-position constraint on positional coordinates'
                     DG   'combination of the above constraints'
                     DR   'combination of the above constraints'
                     DS   'combination of the above constraints'
                     GR   'combination of the above constraints'
                     GS   'combination of the above constraints'
                     RS    'combination of the above constraints'
                     DGR  'combination of the above constraints'
                     DGS  'combination of the above constraints'
                     DRS  'combination of the above constraints'
                     GRS  'combination of the above constraints'
                     DGRS 'combination of the above constraints'

The text of the definition for�_atom_site_refinement_flags refers to a�"concatenated series of single-letter codes", which suggests that combinations of the code are allowed. �This is in contrast to the text at the html version of the dictionary (http://www.iucr.org/__data/iucr/cifdic_html/1/cif_core.dic/Iatom_site_refinement_flags.html) which states (a little ambiguously) "The data value must be ONE of the following:" (my emphasis), before the list of single letter codes.

Is it an oversight that the allowed combinations are missing from the enumeration list for�_atom_site_refinement_flags? As it is, a program validating against the cif_core.dic would (I suspect incorrectly) flag a value of, for example, 'PR' as an invalid value for the item�_atom_site_refinement_flags. �PyCifRW is one such program that flags these concatenated values as being outside the permitted set. Without the allowed combinations being also included in the list, it makes it hard to programmatically validate such combinations. �Alternatively, if combinations are not allowed, then this would render many files as output by SHELXL to be invalid (for example when a hydrogen is riding on a partially occupied atom).

I have a further question about case sensitivity of data values. �The cif specification states that the case of data values must be respected - does this mean therefore that, for example, a value of 'Monoclinic' for�_symmetry_cell_setting (a commonly encountered case, judging by our local database of CIFs) should be flagged as being outside of the permitted set, or should it be allowed as valid?

Thanks,

Richard

_______________________________________________
cif-developers mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/cif-developers

_______________________________________________
cif-developers mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/cif-developers