Discussion List Archives

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

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: Gotzon Madariaga <wmpmameg@lg.ehu.es>
  • Date: Thu, 10 Dec 1998 10:30:46 GMT
On Tue, 8 Dec 1998, Brian McMahon wrote:

> Three questions:
> (1) Does the Group agree that I should implement Howard's scheme as it stands?
> Thus the REFLNS_CLASS category is an addition to the REFLNS_SHELL category,
> and definitions should be modified to make this explicit, e.g.:
> data_reflns_class_[]
>     _name                        '_reflns_class_[]'
>     _definition
> ;              Data items in the REFLNS_CLASS category record details, for
>                each reflection class assigned according to some criterion
>                other than shells of resolution, about the reflections used
>                to determine the structural parameters. Details of each
>                resolution shell are described in the category REFLNS_SHELL.
> ;

I agree

> (2) Does the Group see at this stage a genuine need for a data name such as
> the suggested _refln_diffrn_class_code to identify experimental binning among
> the reflections listed in the refinement lists?

I would not include this additional _refln_diffrn_class_code. However, at
this moment, someone could use two different codes for describing the same
set of reflections, for example:

#Experimental stage
A      'reflections matching criterion A'


#Refinement stage
C       'reflections matching criterion A'

I understand that it is not problematic since CIF,s are for computers and
each set of reflections are consistently defined by *_class_description.
Nevertheless it seems to me that this additional degree of freedom could
obscure CIF interpretation. What 'parser-builders' think about?

 link between _diffrn_reflns_class_code and

> (3) Is the Group happy with the proposed handling of overlapping bins through
> application-specific compound codes?

(Thanks for your explanation) I agree with your initial proposal.

> and a possible fourth...
> (4) is there general agreement with the suggested data names in the two new
> categories?

I agree

> Regards
> Brian


Gotzon Madariaga                          |   E-mail: wmpmameg@lg.ehu.es
Dpto. Fisica de la Materia Condensada     |
Facultad de Ciencias                      |   Phone: 34 4 4647700 (Ext. 2489)
Universidad del Pais Vasco                |   FAX  : 34 4 4648500
Apdo. 644                                 |
48080 Bilbao (SPAIN)                      |

[Send comment to list secretary]
[Reply to list (subscribers only)]