Discussion List Archives

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

Re: [ddlm-group] Interactions with methods

Title:
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.

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.

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.

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.

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.

David
begin:vcard
fn:I.David Brown
n:Brown;I.David
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
email;internet:idbrown@mcmaster.ca
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773
version:2.1
end:vcard


_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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