Discussion List Archives

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

Re: A DDLm problem

I like the idea of defining useful functions in the dictionary that
will not in and off themselves generate tags, but we need to
provide some control over scope and namespaces to make it easy to
combine useful functions from multiple dictionaries -- perhaps
adopting python's module based dotted notation to resolve

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


On Fri, 27 Feb 2009, James Hester wrote:

> Dear David,
> I agree with your diagnosis of the problem, and, rather than clutter
> the dictionary with unnecessary baggage as solutions 1 and 2 do, I
> would suggest a variant of your 3rd solution:
> Solution 4: As beta is used primarily for calculational convenience, a
> dREL function 'beta()' is defined which calculates the beta value.
> The structure factor calculation is rewritten to call this function.
> A given dREL implementation can choose to cache values returned by
> this function to improve efficiency.
> Best wishes,
> James.
>> Tree 3 above can be made to work if the beta form can be made invisible.  It
>> cannot be completely invisible as it must appear in the appropriate CIF
>> dictionary, and its text description will be displayed by any CIF editor
>> such as publCIF or enCIFer.
>> One possible solution is to include a flag in the dictionary definition to
>> indicate that the item should be hidden from the user or deleted after the
>> calculation is complete.
> Invisibility can only be maintained if everyone respects the new DDLm
> attribute that will be created to flag it.  The value will leak out.
>> A second possibility is to give the item a dataname that disguises its
>> identity, e.g., a name such as _atom_site_aniso.intermediate1. The
>> dictionary would contain the .description 'This item is an intermediate in
>> an ADP calculation and is not to be used for archival or retrieval
>> purposes'.
> Better than the first solution, but I believe an unnecessary
> cluttering of the dictionary
>> A third solution would be to rearrange the method for calculating the
>> structure factors so that it works with directly with Uaniso and does not
>> generate beta as an intermediate.  In this case there is no need to define
>> beta in the dictionary.
> Indeed, and if the rewriting
>> I propose that we adopt the second solution, i.e., we agree to use datanames
>> and descriptions that indicate that the item is not to be used for archival
>> purposes.  There will of course be many intermediates that are perfectly
>> acceptable for archiving.  For example, when Uaniso is calculated from Biso,
>> Uiso and Baniso are generated along the way and there is no need to hide
>> them.  Calculation of structure factors would also generate
>> atom_site.intermediate1 items containing the ADPs in the beta form, so the
>> CIF may end up being a bit cluttered, but it should be possible to write a
>> program that would clean up the CIF by removing any unwanted intermediate
>> items.  In any case since external programs only need search for Uaniso, the
>> presence of the other items will be of no concern.
>> I am looking for feed back.  However if I receive none, I will assume that
>> you agree that unwanted intermediates should be hidden by giving them
>> meaningless datanames and text definitions that conceal their content.
>> Please circulate your thoughts on this problem to the whole discussion list.
>> David Brown
>> _______________________________________________
>> comcifs mailing list
>> comcifs@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/comcifs
> -- 
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs

Reply to: [list | sender only]