[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Re: CoreCIF revision 2.3
- To: Multiple recipients of list <coredmg@iucr.org>
- Subject: Re: CoreCIF revision 2.3
- From: Howard Flack <Howard.Flack@cryst.unige.ch>
- Date: Thu, 26 Jun 2003 09:35:53 +0100 (BST)
data_diffrn_refln_status ======================== What data item is used to record the "space group assumed during the measurement of the diffraction intensities." It does not make sense to flag the reflections unless you are told the 'assumed space group'. Indeed I have semantic problems with your 'assumed space group'. If you assumed a space group, you would have used this hypothesis not to measure the assumed space-group-absent reflections. In which case there are no reflections to flag. If you measured all reflections during data collection, you did not assume a space group. It sounds to me, according to your comment, that this is a flag for use in hypothesis testing in the style: If I assume such-and-such a space group, which reflections are systematically absent. However if you have trouble identifying the space group, it means that there are several competing hypotheses to take into account but the proposed data item only allows one hypothesis to be used. > incl > 'Reflection expected to have non-zero intensity' How about: notsysabs 'Reflection considered not to be systematically absent under the assumed space group' is much better. Where does 'incl' come from? Likewise: sysabs 'Reflection considered to be systematically absent under the assumed space group' How about: _definition ; A flag indicating whether a reflection would be systematically absent under the assumed space group. > # STATUS: Open for discussion. I think the proposed data item does not sound to be of much practical use. One would really want a table of statistics and a list of offending reflections for a collection of different space group hypotheses. data_geom_bond_multiplicity =========================== > _definition > ; The number of times the given bond appears in the > environment of the atom listed in > _geom_bond_atom_site_label_1. How about: _definition ; The number of symmetry-equivalent bonds of this type connecting to the atom listed in _geom_bond_atom_site_label_1. because any 'given' bond appears just once but there may also be other symmetry-equivalent bonds around the atom. ('Identity' and 'equivalence' are not identical, in a manner of speaking. They are not even equivalent! For a relation on a set to qualify as being an equivalence relation it must have the properties of symmetry, reflexivity and transitivity. If these properties are upheld, one can then easily prove that the equivalence relation decomposes the set into disjoint classes with every set element in a class. When I explain this to my students most of them must think that I am an old bore. I'm sure you agree. I do.) I hope this is of some use and that you manage to keep to your timetable. ITG deadlines are affecting the system in all sorts of ways. I was worried that Brian had fallen ill with some horrid disease. > July 7 Posting of the cumulative list of the 2.3 revisions so > far reviewed by the CoreDMG with a request for final > CoreDMG approval by July 17. It's unfortunate for you because I'm off to Namibia and South Africa only on 24th July so I shall be able to vote. H. PS: I've still got about one year's worth of COMCIFS e-mails to read and consider.
[Send comment to list secretary]
[Reply to list (subscribers only)]
- Prev by Date: CoreCIF revision 2.3
- Next by Date: Re: CoreCIF revision 2.3
- Prev by thread: CoreCIF revision 2.3
- Next by thread: Re: CoreCIF revision 2.3
- Index(es):