[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Re: Transfer from msCIF: refine_ls_class category
- To: Multiple recipients of list <coredmg@iucr.org>
- Subject: Re: Transfer from msCIF: refine_ls_class category
- From: "I. David Brown" <idbrown@mcmail.cis.McMaster.CA>
- Date: Fri, 30 Oct 1998 13:55:19 GMT
Gotzon wrote: > > Nevertheless I do not agree with the separation in experimental and > refinement classes. Perhaps you know several counterexamples, but in my > opinion any classification of intensities at the refinement stage should > be linked to the measurement stage. For example one could ask always how > many reflections have been measured for a certain parity group or how many > first order satellites. That is why I introduced _diffrn_reflns_class_code > as the parent for the rest of codes. The same would be applicable to the > shells. > The problem here lies in the difference between what people ought to do and what they want to do. Generally cif should be permissive rather than prescriptive. Thus cif should make it possible for people to analyse their refinement by class even if they have not concerned themselves with making the measurements by class. Indeed the measurements may not be available if a refinement is made using structure factors taken from the literature. We need to make provision for this use and not require the classes to be linked back to measurements even if, in cases such as modulated structures, it should be encouraged or even required. It is up to the user (e.g. the editors of Acta Cryst.) to stipulate what information has to be supplied. Cif's role is to make sure the user has the tools to report what is necessary. The only places where cif rightly does not accommodate current practice is when the current practice is wrong. The original version of the dictionary only allowed adp's to be given as U. The macromolecular community required that we added B (though the dictionary includes the recommendation that U is preferred). However, we have not included the ambiguous (hence bad) beta form. The line dividing poor (but occasionally acceptable) and bad practice is not well defined, but forcing the user to create measured reflection classes in order to use refined reflection classes is beyond the mandate of cif. David Brown
[Send comment to list secretary]
[Reply to list (subscribers only)]
- Prev by Date: Re: CIF abbreviations
- Next by Date: Re: Resolution limits
- Prev by thread: Re: Transfer from msCIF: refine_ls_class category
- Next by thread: Re: Transfer from msCIF: refine_ls_class category
- Index(es):