[Date Prev][Date Next][Date Index]
(41) F(000)/Ueq/table joins/area detectors/new audit, publ categories
- To: COMCIFS@iucr.ac.uk
- Subject: (41) F(000)/Ueq/table joins/area detectors/new audit, publ categories
- From: bm
- Date: Wed, 12 Jun 1996 12:35:52 +0100
Dear Colleagues
Ongoing discussions
===================
For the record, from David Brown:
D> D37.1 and D39.1. I agree with the views expressed by Brian T.
D40.1 F(000) with non-integer electrons
---------------------------------------
D> I am sure that David's definition is what Frank, Syd and I had in
D> mind when we were preparing the original core dictionary. It is only in
D> use that one discovers the inadequacy of definitions that looked pretty
D> straightforward at the time. I would recommend adopting David Watkin's
D> definition for the existing dataname.
I have thrown everything in together, so the definition now reads
The effective number of electrons in the crystal unit cell
contributing to F(000). It may contain dispersion contributions,
and is calculated as the sum of the real parts of the scattering
factors at theta = 0.
but I don't think this is sufficiently clear, given especially that the
value is often supplied as an integer. Improvements?
D40.3 Another Uequiv
--------------------
From Nick Spadaccini:
N> Watkin's desire for a geometric mean for Ueq, versus the accepted
N> arithmetic mean is pretty standard stuff isn't it. For a truly isotopic
N> U the two measures are identical, but the Watkin's measure is less
N> affected by wildly varying principal axis values ie U = (1, 10, 100)
N> then Ueq (CIF) = 37, and Ueq (Watkin) = 10. The argument of geometric
N> versus arithmetic mean measures is found in most statistics texts, as
N> well desriptions of in which cases one is more meaningful than the other.
N> As far as Watkin's desire for inclusion in the CIF core, it hard to see
N> why it shouldn't be included as a legitimate measure of Ueq.
D> There is a danger in devising datanames for cosmetic items
D> that are not often used. On the other hand, to introduce private names,
D> e.g. '_watkins_ueq' for an item that might later prove to be popular
D> would require the subsequent introduction of an alias, since files written
D> by David's program will be widely distributed. Perhaps we should
D> consider developing a reserve list of datanames, e.g. in this case
D> '_ueq_geom_mean' that would not appear in the public dictionary, but
D> could be assigned to David for private use in his files. Since his
D> program will, in fact, be used well beyond the confines of his own
D> laboratory, people may start using the name they find in the cif if they
D> find the concept useful, regardless of whether it appears in the
D> dictionary. If a name is likely to slip into use via the back door, it
D> is better that it be '_ueq_geom_mean' rather than '_watkins_ueq'. If the
D> idea does not take off, nothing is lost, since the name was never
D> officially adopted. I would recommend using this procedure only with
D> software that had a reasonably wide circulation.
Well, I don't see the merit in having "semi-official" names. We've trodden
this path often before. Hence I have added the entry below. The journal,
presumably, still insists on a submission reporting _atom_site_U_iso_or_equiv,
even if this new data quantity happens also to be given in the CIF!
Please approve or disapprove this new core definition.
data_atom_site_U_equiv_geom
_name '_atom_site_U_equiv_geom'
_category atom_site
_type numb
_type_conditions esd
_list yes
_list_reference '_atom_site_label'
_enumeration_range 0.0:10.0
_related_item '_atom_site_U_iso_or_equiv'
_related_function alternate
_units A^2^
_units_detail 'Angstroms squared'
_definition
; Equivalent isotropic atomic displacement parameter, U(equiv),
in angstroms squared, calculated as the geometric mean of
the anisotropic atomic displacement parameters.
U(equiv) = (U~i~ U~j~ U~k~)^1/3^
U~n~ = the principal components of the orthogonalised U~ij~
;
D40.4 Symmetry-generated atoms in a site list
---------------------------------------------
I reported CCDC's desire to include atoms generated by symmetry from the
contents of the asymmetric unit but forming part of a connected residue
within the _atom_site list, and asked whether this would break existing
software. Syd responded
S> their inclusion as a cif parameter will certainly blow the XTAL
S> reader out of the water.
David's opinion was
D> I am definitely against expanding '_atom_site_*' to include
D> symmetry generated atoms. We need a second loop, e.g. '_mol_atom_site_*'
D> for a list of atoms that constitute a chemical, rather than a
D> crystallographic, unit. The chemical units are complexes and molecules,
D> the crystallographic unit is the asymmetric unit. I am becoming more and
D> more aware of the difference, often blurred in practice, between the
D> crystallographic description of a structure and its chemical description.
D> MIF is clearly only concerned with the chemical description, and there are
D> clear advantages in matching the chemical descriptions in cif with those
D> of mif. But we need to maintain the distinction between the two
D> descriptions. '_atom_site_*' is a crystallographic description. The site
D> is defined by its crystallographic coordinates, not by the atoms occupying
D> the site. In inorganic compounds, a given site may be occupied by
D> different atoms in different unit cells, or may not be occupied at all.
D> The site is related to the crystallographic cell and its space group
D> symmetry. On the other hand, the category '_mol_atom_site_*' would be
D> chemistry based. It would be defined by the chemical species in the list.
D> The coordinates and their method of generation would be secondary. The
D> coordinate system might be the crystal system, but this is not necessary.
D> An orthogonal coordinate system would work as well, because any
D> crystallographic symmetry is already explicit in the list. This category
D> would then readily match the mif structure - indeed it would be little
D> more than an extension of the _atom_ loop given in the example in
D> comcifs-40. If we define a '_mol_atom_site_' category, the basis set of
D> axes should also be explicitly defined.
I read these as very strong objections to the incorporation of the
symmetry-generated atoms in the sites list; and there is some degree of
consensus that the 3-dimensional molecular description belongs properly to
MIF. Which brings us to...
D40.5 CIF/MIF applications
--------------------------
N> The CCDC stuff is difficult, because they wish to blend in
N> non-crystallographic, but still structure data. You know with these
N> models there is no concept of symmetry, or cell, or fractional coordinates
N> etc. However I would be very wary of making them part of CIF. They are
N> relevant to another STAR File, and CCDC want pointers from CIF to MIF.
N> Fair enough but they should not be part of CIF, otherwise the next interest
N> group may want to connect the author addresses to a Yellow Pages STAR File,
N> and require their pointers be imbedded into the CIF core. A silly example but
N> you know what I am getting at.
But supposing you wish to extract information from the Yellow Pages about
telephone numbers of authors in _publ_author_ ? Still a bit silly, but the
point is that you may wish to make (and store) relations across different
applications dictionaries, as in the CIF/MIF cases we are looking at. How
about this approach (derived in part from the 'glue tables' we are
building for our new database applications)?
Say we want to join together the examples of D40.5, viz
loop_ loop_
_atom_site_label _atom_id
_atom_site_fract_x _atom_type
_atom_site_fract_y _atom_attach_h
_atom_site_fract_z
C1 .1234(5) .3456(7) .5678(9) 1 C 2
C2 .2341(5) .4563(7) .6785(9) 2 C 2
Define a mapping between the overlapping quantities (here the labels of
the atoms in the two tables).
loop_
_audit_join_parent_name
_audit_join_child_name
_audit_join_parent_map
_audit_join_child_map
'_atom_site_label' '_atom_id' C1 1
'_atom_site_label' '_atom_id' C2 2
'_atom_site_label' '_atom_id' C3 3
'_atom_site_label' '_atom_id' O1 4
If the values were the same in each case, the *_map values could be left
out, and the loop collapses to
loop_
_audit_join_parent_name
_audit_join_child_name
'_atom_site_label' '_atom_id'
I hasten to say that this approach has not been fully thought through, and
our database-savvy colleagues will have no difficulty in identifying the
problems; but I hope they can also say whether it has any potential
usefulness.
New topics
==========
D41.1 pointer to conformant dictionaries/(35)D34.1 _units
---------------------------------------------------------
In circular 35 we agreed to the proposals of D34.1 to drop the original
Core conventions for allowing derived data names with different units from
the parent by appending some code, such as _atom_site_Cartn_x_nm. However,
I was troubled by what to do to with existing data files that had availed
themselves of this trick, and resolved it for the time being by
introducing explicit data names into the core, such as _atom_site_Cartn_x_nm,
that had a _units value of 'nm'. Nick Spadaccini took me to task on this:
N> eventually CIF should be
N> purged of _nm _pm _whatever extensions. This may require a retrograde
N> clean out of archives, but so be it. One problem I have with them being
N> in the core is that people see them, and hence will want to use them, and
N> worse still, may see them as the way to go and therefore "request" new
N> ones be added. I think Brian, your suggestion that these no longer
N> supported features be cleaved off to form a separate compatibility
N> dictionary which the users never see is a good solution. If that wasn't
N> what you were suggesting, then let me suggest here.
My problem goes slightly beyond 'cleaning out the archives'; rather I am
troubled by coping in future with files that are written still conforming
to the original Core rules. Anyway, my way out of this is to write all the
existing datanames with units extensions (and of course there will be no
more of them in future) to a 'compatibility dictionary', cif_compat.dic
(available from the comcifs ftp area if you are interested). This will NOT
be included in the core, but can be loaded by an explicit reference in a
data CIF. To permit this, I've introduced into the core the
_audit_conformant_dictionary data name (slightly modified) that was
discussed in D25.6. Here is the new set of entries:
#####################
## _audit_conform_ ##
#####################
data_audit_conform_[]
_name '_audit_conform_[]'
_category category_overview
_type null
loop_ _example
_example_detail
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
_audit_conform_dict_name cif_core.dic
_audit_conform_dict_version 2.0
_audit_conform_dict_location ftp://ftp.iucr.ac.uk/pub/cifdic.c96
;
;
Example 1 - Any file conforming to the current CIF core dictionary.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
loop_
_audit_conform_dict_name
_audit_conform_dict_version
_audit_conform_dict_location
cif_core.dic 2.0 ftp://ftp.iucr.ac.uk/pub/cifdic.c96
mif_core.dic 1.0 ftp://ftp.iucr.ac.uk/pub/mifdic.c93
;
;
Example 2 - A file conforming to the current CIF core dictionary and the
molecular information file (MIF) core dictionary.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_definition
; Data items in the _audit_conform_ category describe the
dictionary versions against which the data names appearing in
the current data block are conformant.
;
data_audit_conform_dict_location
_name '_audit_conform_dict_location'
_category audit_conform
_type char
_list both
_list_reference '_audit_conform_dict_name'
_definition
; A file name or uniform resource locator (URL) where the
conformant dictionary resides.
;
data_audit_conform_dict_name
_name '_audit_conform_dict_name'
_category audit_conform
_type char
_list both
_list_mandatory yes
_definition
; The string identifying the highest-level dictionary defining
datanames used in this file.
;
data_audit_conform_dict_version
_name '_audit_conform_dict_version'
_category audit_conform
_type char
_list both
_list_reference '_audit_conform_dict_name'
_definition
; The version number of the conformant dictionary.
;
Note that this exists alongside the mechanism used in the dictionaries
themselves to import dependent dictionaries. For example, suppose you have
a CIF containing the data name '_atom_site_Cartn_x_nm'. The CIF should
contain an entry
_audit_conform_dict_name cif_compat.dic
Because cif_compat.dic includes the preprocessor directive
data_include_dependent_dictionaries
#\include http://www.iucr.ac.uk/cif/cif_core.dic
this will automatically "pull in" the rest of the definitions in the
current core dictionary. A CIF which didn't need to reference the
deprecated "*_nm" terms could simply have the entry
_audit_conform_dict_name cif_core.dic
Note that I allow the _audit_conform_dict_* items to be looped, so as to
permit input of dictionaries from different disciplines (as illustrated
for the CIF/MIF case), or to permit the import of local dictionaries that
are fully DDL conformant. It is assumed that the same data name will not
be defined differently in the various different dictionaries thus
referenced.
Note also the _audit_conform_dict_location definition is couched in terms
of filenames or URLs, and I have no doubt this will again provoke Brian T.
to remind us that there is no guarantee of portability or durability of
such values. I can remove it altogether, if that is the corporate will of
COMCIFS; or I can leave it in as an item that might, sometimes, get you
the file you want; and as such is better than supplying no clue at all.
Preferences?
D41.2 Area detectors
--------------------
Syd has been encouraging Acta C Coeditors to suggest the best way of
handling area-detector data. Bill Clegg has suggested that the relevant
definitions in the mmCIF dictionary are adequate. Here is an extract from
Syd's newsletter to Coeditors:
S> The CIF data items shown below were submitted by Bill Clegg as
S> possible area-detector parameters for use in Section C. These are a
S> selection of data items from the Macromolecular CIF dictionary
S> (mmCIF) defined by Paula Fitzgerald and her working group.
S>
S> Additional items will probably be needed. For example, data in the
S> item "_diffrn_measurement.details" listed below probably needs to be
S> separated into separate components. It essential for both authors
S> and editors that individual parameters are uniquely identified.
S>
S> Here are the proposed area-detector parameters, used in an actual
S> example.
S>
S> loop_
S> _reflns_shell.d_res_high
S> _reflns_shell.d_res_low
S> _reflns_shell.meanI_over_sigI_obs
S> _reflns_shell.number_measured_obs
S> _reflns_shell.number_unique_obs
S> _reflns_shell.percent_possible_obs
S> _reflns_shell.Rmerge_F_obs
S> 31.38 3.82 69.8 9024 2540 96.8 1.98
S> 3.82 3.03 26.1 7413 2364 95.1 3.85
S> 3.03 2.65 10.5 5640 2123 86.2 6.37
S> 2.65 2.41 6.4 4322 1882 76.8 8.01
S> 2.41 2.23 4.3 3247 1714 70.4 9.86
S> 2.23 2.10 3.1 1140 812 33.3 13.99
S>
S> _diffrn_measurement.device_type 'three-circle camera'
S> _diffrn_measurement.device_specific 'Supper model x'
S> _diffrn_measurement.device_details 'none'
S>* _diffrn_measurement.method '\w scan'
S>
S>* _diffrn_measurement.details
S> ; 440 frames, 0.20 \%, 150 s,
S> detector distance 12 cm,
S> detector angle 22.5 \%
S> ;
S> _diffrn_radiation.detector_type 'multiwire'
S> _diffrn_radiation.detector_specific 'Siemens'
S> _diffrn_radiation.source_type 'rotating anode'
S> _diffrn_radiation.source_specific 'Rigaku RU-200'
S> _diffrn_radiation.source_power '50 kW, 180 mA'
S> _diffrn_radiation.source_target '8 mm x 0.4 mm broad focus'
S>* _diffrn_radiation.collimation '0.3 mm double pinhole'
S>* _diffrn_radiation.monochromator 'graphite'
S>* _diffrn_radiation.type 'Cu K\a'
S>* _diffrn_radiation.wavelength 1.5418
David Brown (as an Acta Coeditor) has already made some response to this:
D> I have no problem with the idea of lifting names from mmcif.
D> However I have a problem with the name _diffrn_radiation_source_power as
D> used in the illustration. I have not checked the definition of this, but
D> the name quite clearly expects the units of watts or KW. If the voltage
D> and current are to be given, they should be given as separate data
D> items. Any item that is numeric should be given in a computer readable
D> way. What use can be made of this information? I don't know, but we
D> have had our fingers burned before by introducing sloppy definitions.
prompting the following response from Syd:
S> area detector parameters: I think the mmCIF items are a good
S> starting point for Acta C. It is immediately clear though that
S> items such as _diffrn_measurement.details will not be adequate
S> for our purposes and probably Paula will need to be alerted to
S> this. The five values in this example are each important and
S> really need to be assigned a separate definition. The same may
S> be true for *.source_power. I too do not like units appearing
S> with numerical values but I hadn't been observant enough to
S> pick this up in the mmCIF dictionary.
I append at the end of this mailing a listing of the relevant definitions from
the mmCIF dictionary. Some (marked with asterisks above) already exist in
the core dictionary; others (like the set _diffrn_radiation.source_type,
_diffrn_radiation.source_specific, _diffrn_radiation.source_power,
_diffrn_radiation.source_target) already represent a finer level of detail
than similar core definitions (in this case _diffrn_radiation_source). I
shall add to the core any other definitions from this set that are
necessary (such as the _reflns_shell_ category).
Now is an opportunity to ensure rigour in these definitions for
area-detector use. Please consider carefully whether they suffice, or
supply definitions for others that are considered essential.
D41.3 Structure within published papers
---------------------------------------
To permit broader use of the CIF format in publications, we propose the
following new category. Comments welcome. These permit the separate
labelling of individual blocks of text (sections, footnotes, appendixes),
but not of tables (in plain text format) or figures. We're still thinking
about how best to handle these latter classes.
#################
## _publ_body_ ##
#################
data_publ_body_[]
_name '_publ_body_[]'
_category category_overview
_type null
loop_ _example
_example_detail
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
loop_
_publ_body_element
_publ_body_label
_publ_body_title
_publ_body_format
_publ_body_contents
section 1 Introduction cif
; X-ray diffraction from a crystalline material provides information on
the thermally and spatially averaged electron density in the crystal...
;
section 2 Theory tex
; In the rigid-atom approximation, the dynamic electron density of an atom
is described by the convolution product of the static atomic density
and a probability density function,
$\rho_{dyn}(\bf r) = \rho_{stat}(\bf r) * P(\bf r). \eqno(1) $
;
;
;
Example 1 - based on a paper by R. Restori & D. Schwarzenbach (1996),
Acta Cryst. A52, 369-378.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
loop_
_publ_body_element
_publ_body_label
_publ_body_title
_publ_body_contents
section 3
'The two-channel method for retrieval of the deformation electron density'
.
subsection 3.1 'The two-channel entropy S[\D\r(r)]'
; As the wide dynamic range involved in the total electron density...
;
subsection 3.2 'Uniform vs informative prior model densities' .
subsubsection 3.2.1 'Use of uniform models'
; Straightforward algebra leads to expressions analogous to...
;
;
;
Example 2 - based on a paper by R. J. Papoular, Y. Vekhter & P. Coppens
(1996), Acta Cryst. A52, 397-407.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_definition
; Data items in the _publ_body_ category permit labelling of
different text sections within the body of a submitted paper.
Note that these should not be used in a paper which has
a standard format with sections tagged by specific data names
(such as in Actac Crystallographica Section C).
;
data_publ_body_contents
_name '_publ_body_contents'
_category publ_body
_type char
_list yes
_list_reference '_publ_body_label'
_definition
; A text section of a submitted paper.
;
data_publ_body_element
_name '_publ_body_element'
_category publ_body
_type char
_list yes
_list_reference '_publ_body_label'
loop_ _enumeration
section
subsection
subsubsection
appendix
footnote
_definition
; The functional role of the associated text section.
;
data_publ_body_label
_name '_publ_body_label'
_category publ_body
_type char
_list yes
_list_mandatory yes
_list_uniqueness '_publ_body_element'
loop_ _example 1 1.1 2.1.3
_definition
; Code identifying the section of text. The combination of this
with _publ_body_element must be unique.
;
data_publ_body_format
_name '_publ_body_format'
_category publ_body
_type char
_list yes
_list_reference '_publ_body_label'
loop_ _enumeration
_enumeration_detail
ascii 'no coding for special symbols'
cif 'CIF convention'
latex 'LaTeX'
sgml 'SGML (ISO 8879)'
tex 'TeX'
troff 'troff or nroff'
_definition
; Code indicating the appropriate typesetting conventions
for accented characters and special symbols in the text
section.
;
data_publ_body_title
_name '_publ_body_title'
_category publ_body
_type char
_list yes
_list_reference '_publ_body_label'
_definition
; Title of the associated section of text.
;
D41.4 Linking data blocks
-------------------------
Actually an old, old chestnut (see D11.1), but what I present here is my
view of the best resolution. This is prompted again by correspondence with
CCDC, who need to be able to handle files with datablocks referring to
different structures or parts of structures. I introduce the category
_audit_link_ to describe how datablocks are related. Here is its current
definition:
#################
## _audit_link ##
#################
data_audit_link_[]
_name '_audit_link_[]'
_category category_overview
_type null
loop_ _example
_example_detail
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
loop_
_audit_link_block_code
_audit_link_block_description
. 'discursive text of paper describing two structures'
(1) 'structure 1 of 2'
(2) 'structure 2 of 2'
;
;
Example 1 - multiple structure paper, as illustrated
in A Guide to CIF for Authors (1995). IUCr: Chester.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;
loop_
_audit_link_block_code
_audit_link_block_description
. 'publication details'
KSE_COM 'common experimental data - reference and modulated structures'
KSE_REF 'reference structure'
KSE_MOD 'modulated structure'
;
;
Example 2 - example file for the one-dimensional incommensurately
modulated structure of K~2~SeO~4~.
;
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_definition
; Data items in the _audit_link_ category record details about the
relationships between data blocks in the current CIF.
;
data_audit_link_block_code
_name '_audit_link_block_code'
_category audit_link
_type char
_list yes
_list_mandatory yes
_definition
; The name of a data block (i.e. the string xxxx in a data
block declaration datas_xxxx) in the current file related to
the current data block. The special value '.' may be used
to refer to the current data block for completeness.
;
data_audit_link_block_description
_name '_audit_link_block_description'
_category audit_link
_type char
_list yes
_list_reference '_audit_link_block_code'
_definition
; A textual description of the relationship of the referenced
data block to the current one.
;
Note that I have NOT included the additional data names proposed by Syd
(_audit_data_block_name, *_date ...) to record any changes to the
data block name. This is deliberate - the use of this mechanism
is to record relationships in the current file; if Acta changes
the name of the datablocks, it must also change the values of
_audit_link_block_code. Our earlier discussions concluded that there was
no merit in using the datablock names as a global reference value across
multiple files. Brian T. has devised a _pd_dataset_id to allow unique
identification and indexing of data sets, and I think that different
communities should be encouraged to employ their own indexing conventions
in this way. I note from circular 12 that Brian can envisage cases where
the same value of _pd_dataset_id can occur in different data blocks.
==============
Lots to digest there, sorry. I had planned to send out ideas on a "little
but often" basis, but the topics above have all come in a rush just
recently.
Brian
##############################################################################
# APPENDIX: Definitions from mmCIF that are appropriate for area detectors #
##############################################################################
save__reflns_shell.d_res_high
_item_description.description
; The highest for the interplanar spacing in the reflection data in
this shell. This is the smallest d value.
;
_item.name '_reflns_shell.d_res_high'
_item.category_id reflns_shell
_item.mandatory_code yes
loop_
_item_range.maximum
_item_range.minimum
. 0.0
0.0 0.0
_item_type.code float
_item_units.code 'angstroms'
save_
save__reflns_shell.d_res_low
_item_description.description
; The lowest resolution for the interplanar spacing in the
reflection data in this shell. This is the largest d value.
;
_item.name '_reflns_shell.d_res_low'
_item.category_id reflns_shell
_item.mandatory_code yes
loop_
_item_range.maximum
_item_range.minimum
. 0.0
0.0 0.0
_item_type.code float
_item_units.code 'angstroms'
save_
save__reflns_shell.meanI_over_sigI_obs
_item_description.description
; The ratio of the mean of the intensities of the reflections
classified as 'observed' (see _reflns_observed_criterion) in this
shell to the mean of the standard deviations of the intensities
of the 'observed' reflections in the resolution shell.
;
_item.name '_reflns_shell.meanI_over_sigI_obs'
_item.category_id reflns_shell
_item.mandatory_code no
_item_type.code float
save_
save__reflns_shell.number_measured_obs
_item_description.description
; The number of diffraction reflections classified as 'observed'
(see _reflns_observed_criterion) measured for this
resolution shell
;
_item.name '_reflns_shell.number_measured_obs'
_item.category_id reflns_shell
_item.mandatory_code no
_item_type.code int
save_
save__reflns_shell.number_unique_obs
_item_description.description
; The total number of diffraction reflections classified as
'observed' (see _reflns_observed_criterion) which are
symmetrically unique after merging for this resolution shell.
;
_item.name '_reflns_shell.number_unique_obs'
_item.category_id reflns_shell
_item.mandatory_code no
_item_type.code int
save_
save__reflns_shell.percent_possible_obs
_item_description.description
; The percentage of geometrically possible diffraction reflections
represented by diffraction reflections classified as
'observed' (see _reflns_observed_criterion) measured for this
resolution shell.
;
_item.name '_reflns_shell.percent_possible_obs'
_item.category_id reflns_shell
_item.mandatory_code no
loop_
_item_range.maximum
_item_range.minimum
. 0.0
0.0 0.0
_item_type.code float
save_
save__reflns_shell.Rmerge_F_obs
_item_description.description
; The value of Rmerge(F) for reflections classified as 'observed'
(see _reflns_observed_criterion) in a given shell.
sumi { sumj | Fj - <F> | }
Rmerge(F) = --------------------------
sumi { sumj <F> }
Fj = the amplitude of the jth observation of reflection i
<F> = the mean of the amplitudes of all observations of
reflection i
sumi is taken over all reflections
sumj is taken over all observations of each reflection
;
_item.name '_reflns_shell.Rmerge_F_obs'
_item.category_id reflns_shell
_item.mandatory_code no
loop_
_item_range.maximum
_item_range.minimum
. 0.0
0.0 0.0
_item_type.code float
save_
save__diffrn_measurement.device_type
_item_description.description
; The general class of the device used to measure the
diffraction intensities.
;
_item.name '_diffrn_measurement.device_type'
_item.category_id diffrn_measurement
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case '3-circle camera'
'4-circle camera'
'kappa-geometry camera'
'oscillation camera'
'precession camera'
save_
save__diffrn_measurement.device_specific
_item_description.description
; The particular device used to measure the diffraction
intensities. In general this will be a manufacturer,
description, model number or some combination of these.
;
_item.name '_diffrn_measurement.device_specific'
_item.category_id diffrn_measurement
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case 'Supper model q'
'Huber model r'
'Enraf-Nonius model s'
'homemade'
save_
save__diffrn_measurement.device_details
_item_description.description
; A description of special aspects of the device used to measure
the diffraction intensities.
;
_item.name '_diffrn_measurement.device_details'
_item.category_id diffrn_measurement
_item.mandatory_code no
_item_type.code text
_item_examples.case
; Need new example here.
;
save_
save__diffrn_measurement.method
_item_description.description
; Method used to measure diffraction data.
;
_item.name '_diffrn_measurement.method'
_item.category_id diffrn_measurement
_item.mandatory_code no
_item_aliases.alias_name '_diffrn_measurement_method'
_item_aliases.dictionary 'cifdic.c94'
_item_aliases.version '2.0'
_item_type.code text
_item_examples.case 'profile data from theta/2theta scans'
save_
save__diffrn_measurement.details
_item_description.description
; A description of special aspects of the data measurement.
;
_item.name '_diffrn_measurement.details'
_item.category_id diffrn_measurement
_item.mandatory_code no
_item_type.code text
_item_examples.case
; 440 frames, 0.20 degrees, 150 sec, detector
distance 12 cm, detector angle 22.5 degrees
;
save_
save__diffrn_radiation.detector_type
_item_description.description
; The general class of the radiation detector.
;
_item.name '_diffrn_radiation.detector_type'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case 'multiwire'
'imaging plate'
'CCD'
'film'
save_
save__diffrn_radiation.detector_specific
_item_description.description
; The particular radiation detector. In general this will be a
manufacturer, description, model number or some combination of
these.
;
_item.name '_diffrn_radiation.detector_specific'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case 'Siemens model x'
'Kodak XG'
'MAR Research model y'
save_
save__diffrn_radiation.source_type
_item_description.description
; The general class of the source of radiation.
;
_item.name '_diffrn_radiation.source_type'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_aliases.alias_name '_diffrn_radiation_source_type'
_item_aliases.dictionary 'cifdic.c94'
_item_aliases.version '2.0'
_item_type.code text
loop_
_item_examples.case 'sealed tube'
'rotating anode'
'synchrotron'
save_
save__diffrn_radiation.source_specific
_item_description.description
; The particular source of radiation. In general this will be a
manufacturer, description, or model number (or some combination
of these) for laboratory sources and an institution name and
beamline name for synchrotron sources.
;
_item.name '_diffrn_radiation.source_specific'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case 'Rigaku RU200'
'Philips fine focus Mo'
'NSLS beamline X8C'
save_
save__diffrn_radiation.source_power
_item_description.description
; The power of the radiation source.
;
_item.name '_diffrn_radiation.source_power'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code line
loop_
_item_examples.case '50 kV, 35 mA'
'8 kW'
'12 GeV'
save_
save__diffrn_radiation.source_target
_item_description.description
; The nature of the cathode target of the radiation source.
;
_item.name '_diffrn_radiation.source_target'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case '8mm x 0.4 mm fine-focus'
'broad focus'
save_
save__diffrn_radiation.collimation
_item_description.description
; The collimation or focusing applied to the radiation.
;
_item.name '_diffrn_radiation.collimation'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code text
loop_
_item_examples.case '0.3 mm double-pinhole'
'0.5 mm'
'focusing mirrors'
save_
save__diffrn_radiation.monochromator
_item_description.description
; The method used to obtain monochromatic radiation. If a mono-
chromator crystal is used the material and the indices of the
Bragg reflection are specified.
;
_item.name '_diffrn_radiation.monochromator'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_aliases.alias_name '_diffrn_radiation_monochromator'
_item_aliases.dictionary 'cifdic.c94'
_item_aliases.version '2.0'
_item_type.code text
loop_
_item_examples.case 'Zr filter'
'Ge 220'
'none'
'equatorial mounted graphite'
save_
save__diffrn_radiation.type
_item_description.description
; The nature of the radiation.
;
_item.name '_diffrn_radiation.type'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_type.code line
loop_
_item_examples.case 'CuK\a'
'neutron'
'electron'
save_
save__diffrn_radiation.wavelength
_item_description.description
; The radiation wavelength.
;
_item.name '_diffrn_radiation.wavelength'
_item.category_id diffrn_radiation
_item.mandatory_code no
_item_aliases.alias_name '_diffrn_radiation_wavelength'
_item_aliases.dictionary 'cifdic.c94'
_item_aliases.version '2.0'
loop_
_item_range.maximum
_item_range.minimum
. 0.0
0.0 0.0
_item_type.code float
_item_units.code 'angstroms'
save_
##############################################################################
- Prev by Date: (40) F(000); neutron diffraction; Uequiv; symmetry-generated sites; MIF
- Next by Date: (42) Submission for approval of Core dictionary version 2.0
- Index(es):