Discussion List Archives

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

Re: [Imgcif-l] imgCIF Standard Axis definition

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@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@iucr.org
>>>  http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>
>> _______________________________________________
>> imgcif-l mailing list
>> imgcif-l@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
> 
> 

_______________________________________________
imgcif-l mailing list
imgcif-l@iucr.org
http://scripts.iucr.org/mailman/listinfo/imgcif-l

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

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

International Science Council 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.

Useful links