A DDLm problem

[James Hester]

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.

> POSSIBLE SOLUTIONS
> 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

>
> THE SOLUTION I PROPOSE TO ADOPT
> 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 at iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>
>



-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148