Crystallography Online: the website of the International Union of Crystallography

Dear Herbert,

There already seems to be some work on using multiple crystals in more 
conventional crystallography, so I wonder if there is way to re-use 
those labels? Perhaps I am trying to put a square peg in a round hole 
here...

Currently there is _diffrn_id in the _diffrn_orient_matrix category, 
which identifies the diffraction experiment. I would suggest adding a 
pointer to the category '_exptl_crystal_id' which might also be called 
'_diffrn.crystal_id' in mmCIF? eg, just add:

'_diffrn_orient_matrix.crystal_id'

...and allow a loop giving a list of orientation matrices all pointing 
at different crystal_id's. This seems to be the 'many crystal' cif 
category, but I don't quite see how to list several crystals in the same 
cif file for now (would I have to give all the crystal colors for grains 
buried inside a piece of rock?). After integration the same data for 
_exptl_crystal_id should then show up in the integrated reflections as:

_refln_crystal_id
and/or:
_diffrn_refln_crystal_id

Somehow it would be useful to distinguish the cases of having several 
crystals and several structure refinements, or several crystals giving a 
single merged dataset and a single refinement. This would be closely 
related to the existing practices dealing with twins in small molecule 
crystallography. People make a dataset from single twin component in 
order to solve the strucuture (shelx hklf 4) and then refine it using 
all the reflections (shelx hklf 5 I think). I've copied this mail to 
Simon Parsons in case he knows how this is done in cif already.

Then for crystal translations mmCIF already has:
'_diffrn.crystal_id'
'_diffrn.crystal_support'
'_diffrn.crystal_treatment'

How about then adding a category:
'_diffrn_crystal_translation'
containing:
'_diffrn_crystal_translation.x'
'_diffrn_crystal_translation.y'
'_diffrn_crystal_translation.z'
'_diffrn_crystal_translation.diffrn_id'
'_diffrn_crystal_translation.crystal_id'

These are x, y, z translations of the crystal with respect to the 
laboratory axes with all goniometer angles set to zero. Units are mm. 
The diffrn_id refers to the diffraction experiment and there must also 
be a matching _diffrn_orient_matrix.diffrn_id entry and a matching 
crystal_id. The axis x/y/z definition here will match that of the 
orientation matrix (and therefore the laboratory co-ordinate system) and 
if the category is absent then these values are assumed to be zero. This 
category is allowed to _loop over all the crystals in the sample.

If the orientation_matrix category contains a UB matrix, one should 
expect to be able to match the unit cell parameters for each crystal to 
the ones that can be derived from UB (eg (UB)^T.UB is the metric tensor, 
which in turn gives the unit cell). Since there are many cif files which 
implicitly assume a single crystal, it seems the default value for 
crystal_id in any category must be assumed as the first and only entry 
in _exptl_crystal_id. Otherwise almost all derived data will end up 
being littered with crystal_id entries. I wonder if orientation matrix 
should have been:

'_diffrn_crystal_orient_matrix.UB[0][0]' etc

where I've added crystal in the label. The orientation matrix is a 
property of the crystal in the diffraction experiment and you can't 
normally find one without mounting your crystal! Is it a bug in mmCIF to 
have this independent of the crystal?

What are your thoughts? Perhaps a new category would be better if this 
is a mis-use of the intentions of crystal_id

Best,

Jon

PS: Apologies if this mail was sent twice.

Herbert J. Bernstein wrote:
> Dear Jon,
> 
>    Your point is a significant one, not a pedantic one -- it comes down
> to what should be refined from the images:  the axis definitions or
> offsets relative to fixed axis definitions.  Let us start with the
> central issue:  where should the origin of the axis system be?  You are
> right -- we have a better chance of a stable axis system against which
> to measure offsets if we use the intersection of two mechanically stable
> axes to set the origin.  Hopefully, the sample will have been mounted
> so that that mechanical origin is bathed by the center of the beam and
> so that that origin is within the sample, so I would proposed the
> following approach to axis definition:
> 
>    1.  The origin of the axis system should, if possible, be defined
> in terms of mechanically stable axes to be in the beam.  If the
> sample goniometer or other sample positioner has two axes the
> intersection which defines a unique point at which the sample should
> be mounted to be bathed by the beam, that will be the origin of the
> axis system.  If no such point is defined, then the midpoint of the
> line of intersection between the sample and the center of the beam
> will define the origin.  For this definition the sample positioning
> system will be set at its initial reference position for the experiment.
> 
>    2.  It the sample positioning system has a principal axis that
> intersects the origin and which forms an angle of more than 22.5
> degrees with the beam axis, the X-axis will point from the origin
> specified above along the principal axis of the goniometer,
> 
>    ... and then continue with the definitions as before using either
> David's simpler approach or the more detailed one suggested on the
> web site.
> 
>    You are also right about the need for multiple orientation matrices.
> I think we need to add a GRAIN or SUBSAMPLE category to list
> the grains and and then an extra _diffrn_orient_matrix.grain_id
> or _diffrn_orient_matrix.subsample_id tag to separate the
> matrices for the different grains.  Would you care to suggest
> the tags for the GRAIN or SUBSAMPLE category itself?
> 
>    Regards,
>      Herbert
> 
> At 12:47 AM +0200 5/4/07, Jon Wright wrote:
>> Hi Herbert,
>>
>>>  1.  No matter how the direction of the X-axis is chosen,
>>>  it is important to place the origin of the X-axis in
>>>  the sample, not in the detector.  Otherwise calculations
>>>  of beam centers and detector distances become
>>>  quite difficult.
>> A pedantic point, but the intersection of the goniometer axes would seem
>> like a first choice of origin for ImageCIF. If there is only one axis
>> then the intersection of that axis with the centre of the beam seems
>> like a second choice. The finite sized sample would then be the last resort.
>>
>> Not sure where they go in the current dictionaries; but the Bruker/Saint
>> practice of refining "crystal translations" during integration are
>> useful data to be recorded. These same numbers come up in grain mapping
>> applications, which is a growing business. These definitions really
>> matter and are usually interesting in terms of an agreed upon laboratory
>> co-ordinate system.
>>
>> I see _diffrn_orient_matrix is in mmCIF (?) We often collect images
>> where the sample is a collection of grains, each having their own
>> orientation and centre of mass. How should multiple crystals be dealt
>> with now, for example with non-merohedral twins?
>>
>> Best,
>>
>>
>> Jon
>>
>>
>>
>>>  2.  If an X-axis is chosen that is different from
>>>  the pricipal axis of the goniometer, it is important
>>>  that it be clearly documented, so that, for example
>>>  the detector axes do not get miss-identified.
>>>
>>>  There is a draft of the current proposal prior to
>>>  David's suggestion at
>>>
>>>  http://www.bernstein-plus-sons.com/software/CBFlib_0.7.7/doc
>>>
>>>  Please do consider what is in the proposal and what
>>>  David has suggested as a modification, and please
>>  > send your comments and suggestions to this list.
>>>    -- HJB
>>>
>>>  =====================================================
>>>   Herbert J. Bernstein, Professor of Computer Science
>>>     Dowling College, Kramer Science Center, KSC 121
>>>          Idle Hour Blvd, Oakdale, NY, 11769
>>>
>>>                   +1-631-244-3035
>>>                   yaya at dowling.edu
>>>  =====================================================
>>>
>>>  On Thu, 3 May 2007, David Brown wrote:
>>>
>>>>  A proposal for the definition of a reference axis system in imgCIF (and
>>>>  by inference other CIF dictionaries).
>>>>
>>>>  By I.David Brown
>>>>
>>>>  The imgCIF dictionary recognizes that authors will require to use a
>>>>  number of different axis systems to describe, e.g., the crystal
>>>>  orientation, the reciprocal space orientation and the detector.  There
>>>>  is clearly a need to be able to relate these axes to each other.
>>>>
>>>>  For this purpose imgCIF defines a standard laboratory coordinate system
>>>>  (SLCS) based on directions that can be derived from the diffraction
>>>>  equipment being used.  Two directions are needed to define the SLCS and
>>>>  in the first version of the imgCIF dictionary, these directions are the
>>>>  incident beam and the spatially fixed rotation axis of the goniometer
>>>>  that holds the specimen.  X is defined as lying along the goniometer
>>>>  axis, Z as perpendicular to this and lying in the plane of X and the
>>>>  incident beam, and Y is chosen to complete a right handed rectangular
>>>>  coordinate system.  The origin is placed at the sample.
>>>>
>>>>  Problems arise if there is no goniometer as may occur, e.g.,  in small
>>>>  angle scattering experiments.  The incident beam will always define one
>>>>  direction, but a second direction is needed to define the X axis.
>>>>
>>>>  A recent proposal made by Bernstein is to use the principal axis of the
>>>>  detector, defined as the direction in which the detector is most rapidly
>>>>  scanned (for 1- annd 2-dimensional detectors).  An alternative might be
>>>>  the direction of the fixed rotation axis of the detector if one exists.
>>>>  The possibility remains, however, that no unique detector direction can
>>>>  be defined.   In this case Bernstein suggests that the Y axis be chosen
>>>>  in the direction of the gravitational field (down) or, in the case where
>>>>  the incident beam is vertical, the Y axis be chosen to point to the north.
>>>>
>>>>  While the original definition in the current imgCIF dictionary is simple
>>>>  and covers the majority of cases, if there is no goniometer the choices
>>>>  for the second axis start to multiply and some seem quite bizarre.
>>>>  Taking directions from the diffraction equipment makes sense because the
>>>>  relationship between the goniometer and the detector is relevant to
>>>>  interpreting the results.  But directions such as 'down' and 'north' are
>>>>  not related to the operation of the equipment or the interpretation of
>>>>  the measurements.  Rotating the apparatus while maintaining the
>>>>  relationship between its individual components would change the SLCS but
>>>>  make no difference to the relationship between the different practical
>>>>  axis systems.
>>>>
>>>>  The sole purpose in defining the SLCS is to allow the relationships
>>>>  between other axis systems to be expressed in a straightforward manner
>>>>  against some common coordinate system.  The way in which the SLCS is
>>>>  defined is irrelevant so long as it is used consistently within a
>>>>  related set of CIFs.  It is easier to interpret the transformation
>>>>  matrices used to define other axis systems if everyone chooses the same
>>>>  SLCS and it is convenient to base this SLCS on the obvious directions
>>>>  defined by the apparatus, but in those cases where the incident beam  is
>>>>  the only natural direction then the choice of the SLCS X axis is
>>>>  arbitrary and there is no reason why everyone need use the same SLCS.
>>>>  Since Bernstein's proposed choice of X axis depends on whether there the
>>>>  sample is mounted on a goniometer, and what kind of detector is in use,
>>>>  whether the incident beam is vertical etc.,  there will no longer be a
>>>>  universal definition applicable to all experiments.
>>  >>
>>>>  PROPOSAL
>>>>  My proposal is to keep the current definition using the fixed axis of
>>>>  the sample goniometer where such a direction exists and otherwise to
>>>>  allow the X axis direction to be chosen arbitrarily by the user with the
>>>>  understanding that it must be used consistently within any set of
>>>>  related CIFs (though it is not obvious that even this restriction is
>>>>  needed since it is only the relationship between the practical units
>>>>  that is ultimately needed).  It is likely that a standard SLCS would be
>>>>  adopted for instruments mounted at a major installation, even for that
>>>>  small subset of experiments that do not involve an identifiable fixed
>>>>  rotation axis for the specimen.   An item should be defined in the
>>>>  dictionary where the user can explain how the X axis has been chosen.
>>>>  This proposal would have the advantage of simplicity without defeating
>>>>  the purpose of the SLCS in those rare cases where the specimen is not
>>>>  mounted on a goniometer.
>>>>
>>>>
>>>  _______________________________________________
>>>  imgcif-l mailing list
>>>  imgcif-l at iucr.org
>>>  http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>
>> _______________________________________________
>> imgcif-l mailing list
>> imgcif-l at iucr.org
>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
> 
>