Discussion List Archives

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

Macromolecular restraints/constraints; 'y' or 'yes'

  • To: COMCIFS@uk.ac.iucr
  • Subject: Macromolecular restraints/constraints; 'y' or 'yes'
  • From: bm@uk.ac.iucr (Brian McMahon)
  • Date: Mon, 27 Sep 93 15:21:20 BST
Dear Colleagues

I have two further items which George Sheldrick has asked me to bring to
your attention. The first (as a response to the macromolecular extensions) I
present without comment, except to remark that the CIF treatment of restraints
and constraints does not always permit a refinement using identical restraints
to be repeated even for small molecules.

G> Restraints (and constraints).  The _refine_ls_restr_type list is
G> presented in the form of loop_ _example which makes it syntactically
G> unnecessary to define them; only about half of the items are intuitively
G> obvious to me (what does ..._it mean ?).  This summary of the restraints
G> is clearly essential and extends the information usually included on the
G> subject in current PDB entries.  It is however still light years away 
G> from being able to repeat a refinement with the same restraints using
G> the same or a different refinement program.  Does cyclops (etc) mind that
G> _refine_ls_restr_target has variable units and dimensions ?  In fact for
G> planarity restraints different programs use quite different 
G> mathematical formulations.  I would like to be able to add some more
G> restraints which are proving very useful for small proteins at relatively
G> high resolution (and large small molecules at relatively low resolution !),
G> i.e. restraints on isotropic and anisotropic displacement parameters and
G> 'similar distance' restraints (i.e. two or more distances are restrainted 
G> to be equal but no target distance is specified). 
G> 
G> We also need a better way of including constraints such as rigid and
G> riding groups and TLS constraints on the displacement parameters.

The second is a small enough point, but touches on a matter of principle:

G> The most commonly asked CIF question from SHELX users is whether 'y' or 'Y'
G> is allowed as an abbreviation for 'yes' in the ..._publ_flag items.  The
G> reason is that I made the default '?' to save trees so that they have to
G> type all the yesses themselves by hand.  Does your software allow this ?
G> If it does, perhaps we could suggest this extension to the committee.

The short answer to this should be 'no way', since the standard codes in the
Dictionary are intended to be sacrosanct. However, I note that in the proposed
revision of the core dictionary, Syd has established a precedent by allowing
'c' as a synonym for 'calc' as an allowed code for _atom_site_calc_flag. So:
should we permit 'y' for 'yes', or insist that Syd reverses his 'calc' change?

This is a matter of relatively small weight, but it does touch on a more
substantial point. My own program (ciftex) will pragmatically allow 'yes'
or 'y' (because, rightly or wrongly, people have been using it). How strict
should CIF software be in validating against the contents of the Dictionary?
My own approach (again, pragmatic) is that data fields may contain ANY string;
processing software is free to attempt to validate the contents of that string
against dictionary enumerations (or numeric ranges) but should 'recover
gracefully' from cases of apparent invalidity. In other words, the program
should NEVER abort and dump core; it probably should not reject the whole file
(unless it has some very good reason for ensuring absolute conformance to the
whole dictionary); it should be prepared to reject the value if it can find no
reasonable meaning for it, but build as complete a model of the crystal
structure as is possible from the data that are present and decipherable.
Any comments on this?

Note, too, that Syd's 'c for calc' concession is not presented in
machine-readable form: presumably it should go in as
loop_   _enumeration  _enumeration_detail
          calc        'calculated from molecular geometry'
          c           'synonym for calc'

Regards
Brian