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

Re: [ddlm-group] Interactions with methods

Dear Colleagues,

   I am travelling for a week or so, but I find this a very helpful 
discussion.  I am particular impressed to David's user-oriented examples. 
I hope we can come to an agreement on an approach that:

   1.  Fully supports the recording of all crystallographically
useful relationships among the values of tags recording in our 
dictionaries to that inconsistent values can be automatically flagged.
   2.  Sufficiently supports the modest subset of those relationships
that are useful in filling in missing values that are likely to be
reconstructable in a reliable manner (e.g. cell volumes), but not
in such a way the we encourage users to leave out large portions of
the data they should enter, diminishing the impact of the validation
provided by item 1 above.
   3.  We do it in such a way that users, journal editors and other
really and truly understand what is going on.

I'll try to say something less motherhood-and-apple-pie-ish when
I am back home.


  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


On Fri, 11 Sep 2009, Nick Spadaccini wrote:

> On 11/09/09 2:25 AM, "David Brown" <idbrown@mcmaster.ca> wrote:
>> Nick has sketched out a clear rational for the assignments of methods in CIFm
>> dictionaries as seen from his point of view as an originator of DDLm.  My job
>> is to critique this from the point of view of a user to see if I can foresee
>> problems.  Murphy's Law says that if something can happen, sooner or later it
>> will happen.  Therefore we need to think of all the possible ways of breaking
>> Nick's elegant scheme.
>> 1. For the dictionary managers, Nick's approach implies that the lines that
>> follow a calculation from the requested item back to the primitives have to be
>> carefully mapped, i.e., the items are arranged in an hierarchy which can, in
>> principle, be travelled in either direction, but which provide a unique path
>> back to the primitives.  Clearly the dictionary manager must be aware of these
>> lines when adding any new method.  I had a quick look at calculations related
>> to the real and reciprocal cells and their various matrices in the
>> proof-of-principle dictionary.  These include only one method per item on a
>> chain that defines the route back to the primitive lattice parameters.  The
>> resulting network of chains looks somewhat like a spider's web!  Most
>> calculations involve more than one input item causing the chains to split as
>> one traces them back to the primitives.  For instance the calculation of a*
>> involves at  least five separate calculations which eventually trace back to
>> all six primitive lattice constants.  Because of this branching, a simple
>> reversal of a calculation is generally not possible so travelling along the
>> chain in the opposite direction will involve a complex, but different,
>> branching as well.  Even in cases where such reverse calculations can be done,
>> they often do not appear to be useful, though no doubt there are cases where
>> they would be feasible and desirable.  The Dictionary Management Group would
>> need to approve the chains of calculation as well as the dictionary code.  In
>> some cases, particularly with the core dictionary, a wider consultation might
>> be desirable.
> In actual fact those calculation were carefully worked out many years ago.
> The way they have been written, the paths can be "reversed". I have just
> looked at them again and I would write things slightly differently. As
> written now there is presumption that the 6 scalar terms, a, b, c, alpha,
> beta, and gamma are absolutely primitive and have to be deposited. If we
> included the necessary "reverse" methods we could start with reciprocal a,
> b, c etc and do everything. Moreover we can have any of the intermediate
> objects, the metric tensor or the orthogonal matrix and derive backward into
> a, b, and c's etc. However I do agree with you statement above, it does
> require a very thoughtful way of laying out your relationships so that one
> can achieve all paths through the relationships.
>> 2.  Nick's approach implies that the CIF is a static document which is
>> initially loaded with primary (and possibly some derived) items.  It is
>> implicit that any derivative items present must be consistent with the primary
>> items, though in practice this may not always be the case.  The user can
>> invoke the methods to fill in missing items, but items further up a chain that
>> includes a derived item that is incorrect will themselves be incorrect since
>> the method search will not look further than an item that is present, whether
>> correct or not.
> This and all the points that follow are completely valid, BUT are an
> application level issue NOT a dictionary and DMG level issue. The CIF and
> the discipline dictionaries will generally be static documents, they become
> dynamic when you use them as you wish to. The dictionary lays out the
> relationships, how, when, why etc you invoke these relationships is up to
> you and not mandated by a dictionary.
>> 3. While the authors of DDLm and CIFm (i.e. us) may intend that methods should
>> only be used to expand the CIF by adding items that were not included by the
>> CIFs author, the users of CIFm may have other ideas.  A not unlikely scenario
>> is that the editors of Acta Cryst. E, being inundated with bad CIFs, decide
>> they need to check some or all of the items in a submitted CIF.  Since the
>> dictionary contains the definitive definitions of each item, what better way
>> to check a CIF than to use the dictionary methods.  They therefore create an
>> application that will recalculate the values of all the items already in the
>> CIF from the primitives, ignoring any intermediate derived items that might be
>> present.  The program would either issue a warning if the submitted and
>> methods values were different, or it might optionally replace erroneous values
>> with those calculated using the methods.  This could be done using a program
>> like CheckCIF to validate all the items present in the CIF, or interactively
>> by one of the editors who wishes to check a single item.  Such an application
>> would be easy to implement and would clearly lie within the spirit of the
>> methods but it would result in changes to the CIF.  This is importantly
>> different from expanding a CIF, since it changes the exercise from one in
>> which CIF values, once calculated, never change, to one in which the values of
>> the CIF can be changed; the output CIF now has values that are different from
>> those in the input CIF,  The CIF is no longer static but dynamic.
> Absolutely this is what I as a user would want to do. Get the value, how can
> I check it? Enforce the full evaluation of the methods and ALL recursively
> called methods and compare. BUT this is not an issue for the dictionary.
> So what you need to implement in your application is something like
> if(_cell.volume != EVALUATE(_cell.volume)) raiseException("blah");
> Of course checking would need to be in place that the value of _cell.volume
> was there in the first place. EVALUATE would be an enforced execution of the
> EVALUATION method. The dictionary provides the EVALUATION methods, the rest
> is a use application issue, not a dictionary issue.
>> 4. The next stage is for the user to ask 'What happens to X if I change Y?'
>> This is a harmless question, and it is one that is easy to answer using the
>> regular methods application.  Because of this it is likely to be asked sooner
>> rather than later.  But it takes the dynamic CIF one step further away from
>> Nick's tidy description of the use of methods. Even though this approach may
>> never be the preferred method of solving structures because of the
>> inefficiency of the methods calculations, it might be an attractive way of
>> exploring the properties of a structure to answer the question, 'what happens
>> to the bond distances if I move one of the atoms or change one of the lattice
>> parameters?'   It is a likely enough question and easy for the methods
>> application to answer since the application will be ready at hand and requires
>> no reprogramming.  It only involves editing the CIF in order to change one or
>> more items before asking for the bond length.  This exercise will almost
>> certainly result in an invalid CIF since most of the derived items will still
>> conform to the original CIF.  The clean-up application described in section 3
>> above will then be needed to bring the CIF into full conformity. This is such
>> an obvious (mis?)use of CIF that it is bound to occur and we cannot afford to
>> ignore it.
> This purely an application level issue and not a dictionary level issue. How
> you want to use the contents of the dictionary is up to the individual.
>> As long as it is possible for a CIF to contain conflicting information, the
>> order in which the methods are attempted will matter.  We could adopt the rule
>> that the method that leads back to the primitives should appear first and be
>> the first attempted.  If this encounters an erroneous value along the way, so
>> be it, the responsibility lies with the user.  However, since the CIF itself
>> is now a changing object, the route followed will not necessarily be obvious,
>> particularly after a number of further revisions of the CIF.   Of course, the
>> validation checker of section 3 could be invoked at any stage to ensure that
>> the CIF is fully conformant before it is further expanded.  In all these cases
>> a log should be kept if only for trouble shooting.  Giving the names of the
>> items involved in methods would be one way, but a much easier form to read
>> would be one that provides a brief description of the method given in the
>> dictionary itself.
> cheers
> Nick
> --------------------------------
> Associate Professor N. Spadaccini, PhD
> School of Computer Science & Software Engineering
> The University of Western Australia    t: +61 (0)8 6488 3452
> 35 Stirling Highway                    f: +61 (0)8 6488 1089
> CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
> MBDP  M002
> CRICOS Provider Code: 00126G
> e: Nick.Spadaccini@uwa.edu.au
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
ddlm-group mailing list

Reply to: [list | sender only]