[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: A DDLm problem
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
- Subject: Re: A DDLm problem
- From: James Hester <jamesrhester@gmail.com>
- Date: Fri, 27 Feb 2009 14:50:05 +1100
- Cc: coreCIFchem@iucr.org
- In-Reply-To: <49A44CAB.4030502@mcmaster.ca>
- References: <49A44CAB.4030502@mcmaster.ca>
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@iucr.org > http://scripts.iucr.org/mailman/listinfo/comcifs > > -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148
Reply to: [list | sender only]
- Follow-Ups:
- Re: A DDLm problem (Herbert J. Bernstein)
- References:
- A DDLm problem (David Brown)
- Prev by Date: Re: A DDLm problem
- Next by Date: Re: A DDLm problem
- Prev by thread: Re: A DDLm problem
- Next by thread: Re: A DDLm problem
- Index(es):