Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enumeration values

Title:
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 cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers


begin:vcard
fn:I.David Brown
n:Brown;I.David
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
email;internet:idbrown@mcmaster.ca
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773
version:2.1
end:vcard

_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.