Discussion List Archives

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

(16) Restraints again; dates; _su (?)

Dear Colleagues

In a recent message, Howard Flack included the following greeting:

H> From H.D. Flack to Comcifs 6 Dec 1993.  Happy Christmas to you all.

Note that this was sent (and received) on the Feast of St Nicholas, when (in
German-speaking countries) the Holy Bishop Nicholas brings gifts to children
who have been good during the past year. Make of that what you will.

Call for Agreement
------------------
A16.1  (This was advanced by David in (15) under the heading 'DDL' and has
       attracted no howls of complaint yet):
       All dates in a CIF should be expressed in the format yyyy-mm-dd
       where y,m,d are digits [0-9], yyyy is the year number in the Christian
       calendar, mm the month number (with leading zeroes) starting from
       01 for January, and dd the day number.

[Is this sufficient for the needs of crystallographers? Is there ever going to
be a need to give a date B.C.? And how to refer to dates in the transition
between Julian and Gregorian calendars, which occurred at different times in
different countries?]

=============== Round-table discussion

A15.1 and/or (12)D4.1: Standard programmer prefixes; restraints
---------------------------------------------------------------

Recall that we have split apart the two threads of discusiion that arose
from our earlier review of restraints handling. We are now proposing the
establishment of a register of reserved prefixes for individual software
developers so that they may devise local data names without fear of colliding
with names devised by others, whether or not they use these local data names
for describing restraints. However, I am tying the two topics together here
because Howard's remarks touch on both of them. He offers something of a
dissenting voice on the allocation of personalised prefixes:
 
H> Restraints. I also entirely dislike the idea of giving each software
H> developer a set of data names. Once defined in this way it will be very
H> difficult to eliminate these programme-specific data names even if it
H> becomes clear that restraint x of system y is identical or closely related
H> to restraint a of system b. Software-developer specific names will hinder
H> the search for a common basis for the proposed restraints.

Although this is said in the context of restraints, there is a general
problem where one (or more) well-considered local data names come to
represent a data item that wins universal acceptance. We need to give some
thought as to how to make the transition between local and global
recognition. If, one day, _shelx_good_wheeze is adopted as a core item
(presumably '_good_wheeze'), will there be any way of extracting the value of
'_good_wheeze' not only from CIFs conforming to the new core dictionary, but
also from the 10,000 archived CIFs where the same information is already
present, but under the local name of '_shelx_good_wheeze'?

Back to restraints...

H> The restraints (and constraints) need to be specified in the CIF describing
H> the refined results. The weight of the restraint in the refinement should
H> be specified. There are certainly different ways of doing some of the 
H> restraints (especially the planarity restraint) which lead to different 
H> results. These restraints being a priori judgements on the model one uses to 
H> refine, a restraint might work better in some cases than in others. It only
H> depends on how good a guess you made in the first place and how well the
H> restraint applies in the case you are treating. I do not see it as "there
H> is not yet agreement".

[This specifically in reference to Syd's remark in (4) that this "is a thorny
issue ... because there is not yet agreement among the experts on how these
processes should be handled or described."]

H>                        Clearly, however, some restraints never correspond to
H> crystal reality (e.g. a C-C distance in a phenyl ring of 0.23nm).
H> You need a CIF name for each different type of restraint. There is a problem
H> which I think Paula mentionned somewhere, of programmer obscurantism. If
H> you can not find out by reading the documentation what the programme does,
H> it is clear you will have trouble writing down a CIF definition. It is
H> nevertheless most unwise to define the restraint in terms of the computer
H> programme. It should only be done in terms of the physical model.

H> It may be that Syd's remarks refer to this sentence of George which I do not
H> understand:
H> G> We also need a better way of including constraints such as rigid and
H> G> riding groups and TLS constraints on the displacement parameters.
H> Does G mean by  "better way of including" 
H> (a) he wants new ways of dealing with these models in the refinement 
H> or (b) he wants new ways of writing down in a CIF the existing models.
H> If it's (a), then I do not think that this is the work of this Committee. 

I would read George's remark as referring to the difficulties in describing
what has already been done in an appropriate archival format. However, I
expect that contributions to (a) would not be turned away just because they
came from members of this Committee!!

And, coming back to the problem of describing the restraints within CIF:

H> It seems to me that there is a set of restraints for which the definition of 
H> the restraint is not in doubt. These should be given their own cif datanames.
H> I do not think that they should be defined by way of enumeration lists. (In
H> this realisation, the prolsq angle restraint would then be named as a
H> distance restraint, since that is what it is). Certainly it would be unwise
H> to give some of the newer restraints which are still in an experimental
H> stage and have yet to prove their general applicability and acceptance,
H> a cif dataname.

George has also returned to this topic:

G> In case I have a vote, I would like to cast it in favour of major software
G> suppliers being assigned reserved names, or more precisely that _shelx_
G> should be assigned to me.  I thought that this had been more or less agreed
G> until I noticed a negative comment from Paula recently.  David is quite
G> correct in assuming that restraints were only an example; indeed it is
G> just conceivable that we could agree on a better way to handle restraint
G> information, but there are many other matters specific to a particular
G> program which are nevertheless worth preserving for posterity. 
G> You must remember that I have been through
G> this process before when I negotiated with Syd about CIF output for small
G> molecules.  At the time I was under considerable time pressure because I
G> wanted to get SHELXL-93 out in time to be useful for CIF submissions to Acta
G> C, and perhaps allowed myself to be influenced too much by Syd's eloquent
G> arguments for not making changes to CIFDIC.C91, with the result that a lot
G> of useful information is not getting into the CIF files.  For example, the
G> small-molecule CIF does not provide nearly enough information on the
G> generation and (constrained or restrained) refinement of hydrogen atoms. 
G> SHELXL-93 G> provides a large number of options for this, about half of
G> which are probably unique to this program; it would be relatively easy to
G> define these with a small number of _shelx_ type data names.  To judge by
G> the number of letters we have received from them over the years asking
G> what we did to the hydrogen atoms, the CCSD might well be interested in these
G> _shelx_ items too.  I must emphasise that this is just one of many examples.

I presume there will be no problem in allocating _shelx_ to George! When the
principle of establishing a register of data names is formally accepted (and
there seems to be no objection to this general principle, pace Howard above),
we need to explore the mechanics of doing this. Then we need to advertise its
existence to the world. How to do this? Howard's comment below on a mechanism
for disseminating the draft dictionaries to the community is apposite:

D12.1.3: Schedule
-----------------
H> Make use of CONCISE and the usenet sci.techniques.xtallography for these
H> announcements

16.1 esd
--------
Bishop Nicholas left us one further present (see, we must have been good
children):

H>  In message (10), Brian mentions _esd.  A working group of the Nomenclature
H>  Commission, following an ISO publication called "Guide to the Expression
H>  of Uncertainty in Measurement" will recommend as IUCr policy that the term
H>  "estimated standard deviation" be replaced by the term "standard
H>  uncertainty".  A further recommendation will become dogmatic about the 
H>  the number of significant digits to be reported for an su.

Regards
Brian