Discussion List Archives

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

Re: [Imgcif-l] imgCIF Standard Axis definition

Dear Colleagues,

   We have three intermixed threads in this discussion:

   The standard axis definition
   The handling of multiple grains in SAS
   Keeping the raw data imgCIF file clean and uncluttered

I have had an off-list request to keep all three threads together,
since this is an interesting discussion, so here goes:

   On the standard axis defintion, I seem to hear no objection to
incorporating Jon's suggestion on using an appropriate goniometer
axis definition, if available, to define an origin.  Are there
any strong feelings about David's comments on the currently proposed
fallbacks to (gravity or north) deal with the cases in which there
is no sample positioner with axes sufficiently distinct from
the beam axis and there is no appropriate axis direction suggested
by detector axes?

   On the handling of multiple grains, Jon has suggested "adding a
pointer to the category '_exptl_crystal_id' which might also be called
'_diffrn.crystal_id' in mmCIF".  The category definition of exptl_crystal
is:

  "Data items in the EXPTL_CRYSTAL category record the results of 
experimental measurements on the crystal or crystals used, such as 
shape, size or density."

If a domain is a crystal, then what Jon proposes would seem to be
a legitimate use of EXPTL_CRYSTAL.  We don't have to litter
other categories with .crystal_id tags if we make the tag "implicit".
I'll say more about that approach in talking about clutter below.
A related question is whether we need two levels of identification,
so we can have multiple rocks as well as multiple crystals within
each rock.  If there is such a need, then we should add an
EXPTL_SAMPLE category as well.

   mmCIF basically assumes everything depends in there being a crystal.
These days that is clearly too narrow a view, but in the case of
a UB matrix, can we have one without a crystal?

   On the question of cluttering raw data imgCIFs, I like the approach
the Kim Henrick originally suggested, data harvesting:  each program
or subsystem collects whatever data is appropriate to what it does
and the values it provides are harvested to populate the overall
record of the data collection, the data processing, etc.  With that
in mind, it would seem sensible for experimentalists to produce
what I like to call "miniCBFs", imgCIF files that have the actual
data and just as much header information as is known and needed
at that stage of the experiment.  Later in the life of the
experiment other mmCIF, imgCIF, sasCIF data would be added
as needed to the original CBF or multiple CIFs would be
collected for a later merge.  If we are careful, by the end
of the entire experiment the composite CIF or collection of
CIFs will be a very useful electronic notebook of the experiment.
The implications for software writers are:

   1.  When reading a CIF, skip the tags that you don't need
for the processing you do.

   2.  When writing a CIF, put whatever you think should be
keep for posterity into the output CIF as parseable CIF data,
not as comments.

   3.  Don't overwrite or delete earlier stage CIFs unless you
have carried all tags and values over to a CIF that will be kept.

   In order to make it easier to write miniCBF's I propose to change
many of the tags that are intended to disambiguate multiple
diffraction experiments to be implicit, so that the default
assumption will be that a CBF contains the data from one
diffraction experiment and we will not have to repeat a dummy
diffrn_id of DS1 over and over again.  In order to satisfy
programs that need fully populated CIFs I am working on
a program convert_minicbf to fill in the missing items from
a template.

   Regards,

   -- Herbert


I've pruned the tail of replies -- it was getting a bit long.
-- 
=====================================================
  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
=====================================================
_______________________________________________
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.