[Date Prev][Date Next][Date Index]
(76) COMCIFS review; imgcif workshop; core 2.1beta; towards mmCIF 2.0
- To: COMCIFS@iucr
- Subject: (76) COMCIFS review; imgcif workshop; core 2.1beta; towards mmCIF 2.0
- Date: Mon, 17 Nov 1997 11:55:40 GMT
Dear Colleagues
Existing discussion threads
===========================
D70.1 COMCIFS Review
--------------------
Howard Flack commented on a couple of points in my suggestions for the
reorganisation of COMCIFS.
> (1) executive
> (2) dictionary subcommittees
> (3) technical working groups
H> Think of another word for "executive"
The terminology is, of course, less important than the stratification of
function. The role of the top layer would be to define the strategy for
future developments and to decide on policy issues affecting CIF as a whole.
"Steering committee", "voting body", Howard's humorous (I think!) suggestion
"praesidium", or any similar title would do as well.
> On the other hand, there are several bodies who feel that they have a right
> to representation in this forum, and they might have Observer status. Likely
> candidates would be the IUCr President, representatives of the Database
> Committee, Electronic Publishing Committee, Journals Commission, Nomenclature
> Commission.
H>
H> This arrangement would suit the EPC perfectly.
> The executive should conduct open discussion through a mailing list
> (membership of which should be restricted to the executive and, perhaps, the
> Observers) and not through the current moderated discussion. In like manner,
> the subcommittees and technical working groups may conduct their business
> through separate mailing lists. It would be beneficial to manage all the
> mailing lists through Chester, or at least to mirror the discussions there.
H>
H> I agree that open discussions should be conducted through a restricted
H> membership mailing list. The current moderated discussion technique
H> strikes me as rather time-consuming on the poor secretary. One has to
H> insist that the mail list users make correct use of the "Subject" so the
H> mail reader may identify the threads, and try and teach them to send
H> several messages each containing comments on one single subject rather
H> than one message with many subjects.
D75.2 Image Workshop
--------------------
From Howard Flack:
H> Concerning the "binary" problem. The neutron scattering group developing
H> Nexus uses HDF for which one of the data structures are binary. Would it
H> not be a good idea for COMCIFs and the Nexus to try and work together to
H> avoid the development of contradictory standards?
Yes. There was a very interesting presentation on Nexus during the Brookhaven
workshop. There were doubts that the HDF format was appropriate for the uses
envisaged, but there was very real enthusiasm for working together to
prevent divergence of the data representation tokens (equivalent to CIF data
names) so far as possible. Although the Nexus project permits the
introduction of new dataname tags with few restrictions (and this is
appropriate for describing essentially unique experimental apparatuses),
there is obvious merit in choosing "standard" tags that map on to the
existing data structures in the CIF descrptive framework. I hope that
COMCIFS will be able to liaise with the Nexus people through the imgcif
working group.
Andy Hammersley circulated the following report to the members of the imgcif
mailing list, and has kindly given me permission to redistribute it here. It
provides a more complete review of the technical issues that were addressed
at the Brookhaven workshop. Members of COMCIFS who are interested in
following the detailed discussions on the implementation of these ideas are
reminded that there is an open discussion list, which is currently quite
active. To subscribe, send email to listproc@bnl.gov as described below:
mail listproc@bnl.gov
Subject: Subscribe
subscribe imgCIF-l <your name>
From: Andy Hammersley <hammersl@esrf.fr>
To: imgcif-l@bnl.gov
Subject: imageNCIF Workshop
Hello Everyone,
This is a "short" summary of some of the discussion topics and conclusions
reached at the Brookhaven imageNCIF workshop 20th-22nd October 1997.
I'm not trying to cover everything, but just the "main" points which
I recall. Bob Sweet has undertaken to produce a report on the workshop
with help from various of the attendees. This report will doubtless
cover more points and in greater detail, but owing to other commitments
will probably not appear until December.
I should start by thanking Bob Sweet, John Skinner, and Ann Emrick for a
very well organised and enjoyable meeting, and thank the sponsers.
I should emphasise the very constructive nature of all the discussions
and underline the unanimous views on a number of major components of
the format, and near unanimous view on other components. This was a very
positive meeting and we can now proceed with the format given that
the major outline has been decided.
Conclusions:
o The format will consist of one or more pseudo-ASCII header sections
followed by binary sections, using a DDL2 based dictionary.
(I see this as a combination of some of my CBF proposal, together
with John Westbrook's dictionary. The multiple binary sections means
that extra syntax is necessary.)
o One or more pure ASCII text encodings may be produced from the
binary "working" files. It is thus appropriate to define an
"imgCIF" dictionary using DDL2. (Herb Bernstein has kindly offered
to handle the translation programs from binary to ASCII and vice
versa. This allows us to concentrate on the binary format.)
The imgCIF dictionary will be used both within the binary format
and within fully CIF compliant ASCII text translations.
DDL2 is necessary to defined inter-relatedness and inter-dependencies
of data items. The alias mechanism can be used to define corresponding
data names for DDL1.4 applications.
o "imgCIF" can be initially defined as a "local" dictionary (CIF
terminology). Later it can be submitted for official approval and
status, or maybe included in the core dictionary.
(Don't worry about the term "local": A "local" distionary can be
widespread.)
o The format will be called the "Crystallographic Binary Format":
CBF (pronounced "sea-biff" !) Recommended file extension "cbf" or
"CBF". (Infact on day one it was decided to call the format
"Binary Information File": BIF, but on day 2 CBF was preferred.
Do we stick with CBF ? )
o The overall file structure was decided:
File Signature (pseudo-ASCII *)
(Also known as the file identifier or "magic number")
Consists of a number of standard invariant characters
Followed by a version number.
Beginning of Header section identifier
Maybe this should be optional for the first header section (?)
Header Section (pseudo-ASCII *)
Contains imgCIF and other CIF data names / values
May contain one or more data blocks.
End of header identifier (pseudo-ASCII *)
White space may optionally be used to align binary to
word/page/block boundaries
Beginning of Binary Section Identifier (binary)
This will start with ASCII printable characters, but will
also include non-printable characters such as ^L ^Z ^D
to separate text from binary data and to indicate the end of the
"header" section to various operating systems.
The number of bytes to jump to the "End of Binary" identifier
will be contained within the identifier. This value may be
undefined, which means that no further binary nor pseudo-ASCII
sections follow the binary section.
(Should each binary section contain an array id value which can
be used to relate the "arrays" defined in the header section
be the different binary sections ? I address this question
mainly to John Westbrook.)
The precise end of the identifier will define the start of
the binary data.
Binary Section
Data whose sense has been fully defined by "_ARRAY." data names,
(Maybe eventually other data names.)
End of Binary Identifier
This is redundant information, but is deliberately present for
safety. In the case of a corrupted file could be used to
recover data after the corrupted binary section.
Using sufficient uniquely defined characters can make the
probability of finding such a sequence in the binary vanishingly
small.
[Repeat of above from "Beginning of Header" identifier]
End of File
* pseudo-ASCII is "lines" of printable ASCII characters separated
by carriage return and linefeed characters, independent of the
operating system being used. (Should horizontal and
vertical tabs also be allowed ? Is there a maximum allowed "line"
length ?)
One pseudo-ASCII section may contain multiple data blocks, and
one data block may define multiple binary sections.
(I will provide a fully detailed proposal for the overall syntax
in the near future.)
o A coordinate system flexible enough to fully describe non-ideal
diffracton geometries was defined. Jim Pflugrath will produce a
detailed description of the system (?). This scheme includes the
generalised concept of a "gravity" vector. (Note: It is intended
to perform diffraction experiments in the Space Shuttle !)
o A preferred rastering scheme was defined. All rastering schemes are
defined looking from the sample to the detector with the "gravity"
vector upwards (my wording is probably not watertight). The
"preferred" scheme is rastering from left to right (fastest), and
then from top to bottom (slowest).
o A structured framework for defining data name categories to fully
describe "experiments" ("investigations" ?) consisting of multiple
data-sets, which may contain multiple "frames", which may contain
data from multiple detectors was defined.
(I think the scheme as defined was not quite complete, but its
extension should be relatively simple.)
John Westbrook will hopefully lead the task group to define data
item categories and data items.
o A number of sources of extra data names which need to be defined to
fully describe the source and experiment were defined.
A task group will work on defining the new data names.
o A number of data items will be defined to describe whether the
data is raw, or has been "corrected" for a number of "distortions"
e.g. detector offsets, data current, zingerings, intensity
non-linearity, spatial distortion, non-uniform intensity response.
o Data names to define processing requirements were discussed, but
further work is necessary.
A task group will work on defining the new data names.
o Methods to automatically describe to processing software series
of files which form a data-set were discussed e.g. templates.
Further definition probably belongs to the above task group.
o "Three" types of lossless data compression algorithms will be included
in version 1: 1 None, 2 Simple byte offset, 3 Choice of simple
predictors followed by Huffman encoding.
(The details of the 2 proposed compression algorithms will be
sent to Herb, so that it can be checked that they do not cause
potential legal problems owing to patents.)
o Availability of a highly portable freely distributed and adaptable
software I/O library was discussed.
The library will be written in ANSI-C.
Fortran and C++ interfaces will be available.
Error reporting should be performed through defined
return error codes.
Debugging options should be available.
o An initial V0.1 software implementation was discussed.
Given the inclusion in V1 of multiple binary sections, various
different data types, etc. it was decided to initially
implement a sub-set. i.e. Only one binary section, and
only 16-bit and 32-bit integer support. Re-rastering will
not be included.
Andy Howard has notes on further details of the proposed
implementation.
o The level of commitment to implementing the format from both
commercial and non-commercial participants was very high.
o A task list and corresponding task groups was defined.
Andy Howard will report on this.
----------------------
Forgive me for the items which I've forgotten. I'll add items to this
list if there are suggestions.
Best Regards,
Andy
================================
New topics
==========
D76.1 Core CIF Dictionary - revision to accommodate Acta C Notes for Authors
----------------------------------------------------------------------------
As far back as the beginning of the year, COMCIFS gave implicit approval
for the introduction of new data names required by Acta Crystallographica
Section C (see circular 54). These were mostly changes of nomenclature to
deprecate the use of the terms "thermal displacement", "estimated standard
deviation" and "observed". These changes have been worked up into formal
definitions which are listed in an appendix to this mailing. There is one
additional data name that falls outside of this group, and that is
"_reflns_number_Friedel". I would ask you to check through these
definitions, and let me know of any errors, ambiguities or lacunae. I shall
post the complete dictionary on the web as version 2.1beta1 on 28 November,
to permit general public scrutiny, and request formal approval at the
beginning of 1998. This is a convenient opportunity to submit additional
data items that you feel are lacking from the Core.
D76.2 Maintenance of the mmCIF dictionary
-----------------------------------------
The preceding item is a reminder of the need to have an efficient rolling
program for maintaining the published dictionaries. It is my hope that the
work that I've been doing with John and Herbert will provide a protocol for
the effective management of a truly distributed dictionary. In the meantime,
the mmCIF working group has proposed its own modus operandi for taking the
macromolecular dictionary to the next release. This scheme has been posted
publicly on the mmCIF discussion list, and I reproduce it here for the
information of COMCIFS members. I consider the model of an editorial board
rather attractive, and invite members to consider whether it could be an
appropriate model for COMCIFS itself. This proposal has been put together by
Helen Berman and Paula Fitzgerald.
Dear Colleagues,
As a result of discussions during and subsequent to the mmCIF Software
Developers' Workshop that was held at Rutgers October 17-19, 1997, we have
written a plan for managing the extension of the mmCIF Dictionary. We
present it here for your information and comments.
As noted in item 2.4 below, all comments and reviews will be carried out via
the mmCIF listserver.
Helen Berman
Paula Fitzgerald
-------------------------------------------------------------------------
A Plan for Extending the mmCIF Dictionary
The following outlines the plan by which the evolution of the mmCIF
dictionary will be managed. This plan would ensure timely additions to the
dictionary, review by experts in the field, and the assurance that the
dictionary will remain technically sound. The model is that of a journal.
1.0 Establishment of a Dictionary Editorial Board
1.1 An Editorial Board will be established whose role will be to review
the proposed new data items. The board members will represent the broad
category groups of the dictionary. Potential candidates have been identified
and are being invited to serve.
1.2 Paula Fitzgerald, who will serve as Editor, and Helen Berman, who
will serve as Associate Editor, will be responsible for initial review of
proposed new data items and for sending them out for review by the
appropriate member(s) of the board.
1.3 Two technical editors, John Westbrook and Herb Bernstein, will be
responsible for ensuring that the definitions are compliant with the
dictionary syntax.
1.4 The editors will meet on a published schedule several times a
year. The full board will meet once a year at the ACA meeting and on an
ad-hoc basis as needed.
2.0 Procedures for Extending the mmCIF Dictionary
2.1 All proposed extensions to the dictionary will be submitted
to the mmCIF server in the form of a dictionary entry. To facilitate this, a
definition template will be made available on the mmCIF server.
2.2 The proposed definitions will receive a preliminary review by the
editorial staff and will then be sent to the appropriate board member(s) for
scientific content review. The reviewers will receive full dictionary
definitions and will return them with corrections and/or modifications.
2.3 Once definitions have been approved they would be put into a
provisonal extensions dictionary. If the proposed data item was submitted
with a local data name prefix, that prefix will be removed in the entry in
the extensions dictionary, but an alias to the local dictionary name (with
the extension) will be retained. A policy for retentions times for these
aliases is under discussion.
2.4 The provisional dictionary will be available on the mmCIF server
and will be updated on a continuing basis. Members of the community at large
will be encouraged to monitor the evolution of the extensions dictionary
via the mmCIF web page, and to comment on all new data items via the mmCIF
list server.
3.0 Proposed Timetable for Extending the mmCIF Dictionary
3.1 For review of Version 2 extensions, the meeting dates for the
Editor and Associate Editor will be December 1, 1997, January 12, 1998,
February 9, 1998 and March 16, 1998.
3.2 On April 1, the extensions dictionary will be sent to COMCIFS
for preliminary technical review.
3.3 Full community review will begin on April 15, 1998 and conclude
on May 16, 1988, at which date the extensions dictionary will be sent to
COMCIFS for formal approval. Once approved, the extensions dictionary will be
merged with Version 1.0 of the mmCIF dictionary, and the merged dictionary
will be published as Version 2.0.
--
D76.3 Version numbering
-----------------------
A point that arises from the above proposal is the style for numbering
subsequent versions of the dictionaries - Paula and Helen are proposing that
the next release of the mmCIF dictionary with enhanced content should be
version 2.0. I have taken the view with the Core dictionary that the first
(1991) release differs from the current release not only in content, but
also in formalism - DDL version "0" versus DDL 1.4, and that this is the
primary reason for having different major version numbers (i.e. core CIF
versions 1.0 and 2.0.1). Hence I anticipated that the next core release would
be version 2.1, and not 3.0. However, it makes sense that we progress the
versioning according to similar principles across our growing family of
dictionaries. I have no objections to increasing the major version number
with each addition of significant content (other than the slight worry I
have when I use the emacs editor version 19.16 that the authors could
surely have got it right before now!), but I'd like to hear what other
members think.
Best wishes
Brian
##############################################################################
APPENDIX Changes to the core CIF Dictionary
The core dictionary is a large enough document that it is inconvenient to
post, and difficult enough to extract unambiguously the changes between
versions. I therefore include here some indications of the changes that
have been made, but encourage you to download and look at the full version
to resolve any ambiguities that you find. the full version is at
ftp://ftp.iucr.org/cifdics/cif_core_2.1beta.dic
The following data blocks have been modified. ("<" flags data blocks that
have been deleted, ">" ones that have been added. Deletions from the older
dictionary file indicate that a composite definition has been broken up into
multiple definitions in the newer dictionary - for example to indicate that
an "..._obs" data name should be replaced by a "..._gt" one.)
> data_atom_site_adp_type
> data_diffrn_measured_fraction_theta_full
> data_diffrn_measured_fraction_theta_max
> data_diffrn_detector_area_resol_mean
< data_diffrn_reflns_theta_
> data_diffrn_reflns_theta_full
> data_diffrn_reflns_theta_max
> data_diffrn_reflns_theta_min
< data_refine_ls_goodness_of_fit_
> data_refine_ls_goodness_of_fit_all
> data_refine_ls_goodness_of_fit_gt
> data_refine_ls_goodness_of_fit_obs
> data_refine_ls_goodness_of_fit_ref
< data_refine_ls_R_factor_
> data_refine_ls_R_factor_all
> data_refine_ls_R_factor_gt
> data_refine_ls_R_factor_obs
< data_refine_ls_restrained_S_
< data_refine_ls_shift/esd_
> data_refine_ls_restrained_S_all
> data_refine_ls_restrained_S_gt
> data_refine_ls_restrained_S_obs
> data_refine_ls_shift/esd_max
> data_refine_ls_shift/esd_mean
> data_refine_ls_shift/su_max
> data_refine_ls_shift/su_mean
< data_refine_ls_wR_factor_
> data_refine_ls_wR_factor_all
> data_refine_ls_wR_factor_gt
> data_refine_ls_wR_factor_obs
> data_refine_ls_wR_factor_ref
> data_refln_include_status
< data_reflns_number_
> data_reflns_number_Friedel
> data_reflns_number_gt
> data_reflns_number_observed
> data_reflns_number_total
> data_reflns_threshold_expression
> data_reflns_shell_meanI_over_sigI_gt
> data_reflns_shell_number_measured_gt
> data_reflns_shell_number_unique_gt
> data_reflns_shell_percent_possible_gt
> data_reflns_shell_Rmerge_F_gt
> data_reflns_shell_Rmerge_I_gt
The following definitions are new (the unusual layout here is a feature of
the software I have used to extract these items from the full dictionary
file):
data_atom_site_adp_type
_name '_atom_site_adp_type'
_category atom_site
_type char
_list yes
_list_reference '_atom_site_label'
loop_
_enumeration
_enumeration_detail
Uani 'anisotropic Uij'
Uiso 'isotropic U'
Uovl 'overall U'
Umpe 'multipole expansion U'
Bani 'anisotropic Bij'
Biso 'isotropic B'
Bovl 'overall B'
_definition
; A standard code used to describe the type of atomic displacement
parameters used for the site.
;
data_diffrn_measured_fraction_theta_full
_name '_diffrn_measured_fraction_theta_full'
_category diffrn
_list yes
_type numb
_enumeration_range 0:1.0
_definition
; Fraction of unique (symmetry-independent) reflections measured
out to _diffrn_reflns_theta_full.
;
data_diffrn_measured_fraction_theta_max
_name '_diffrn_measured_fraction_theta_max'
_category diffrn
_list yes
_type numb
_enumeration_range 0:1.0
_definition
; Fraction of unique (symmetry-independent) reflections measured
out to _diffrn_reflns_theta_max.
;
data_diffrn_detector_area_resol_mean
_name '_diffrn_detector_area_resol_mean'
_category diffrn_detector
_type numb
_enumeration_range 0.0:
_units mm^-1^
_units_detail 'pixels per millimetre'
_definition
; The resolution of an area detector, in pixels/mm.
;
data_diffrn_reflns_theta_full
_name '_diffrn_reflns_theta_full'
_category diffrn_reflns
_type numb
_enumeration_range 0.0:90.0
_units deg
_units_detail 'degrees'
_definition
; The diffractometer theta angle (in degrees) at which the
measured reflection count is close to complete. The fraction
of unique reflections measured out to this angle is given by
_diffrn_measured_fraction_theta_full.
;
data_refine_ls_goodness_of_fit_gt
_name '_refine_ls_goodness_of_fit_gt'
_category refine
_type numb
_type_conditions esd
_enumeration_range 0.0:
_definition
; The least-squares goodness-of-fit parameter S for
significantly intense reflections, (see
_reflns_threshold_expression), after the final cycle of
refinement. Ideally, account should be taken of parameters
restrained in the least squares. See also
_refine_ls_restrained_S_ definitions.
{ sum | w | Y(obs) - Y(calc) |^2^ | }^1/2^
S = { ----------------------------------- }
{ Nref - Nparam }
Y(obs) = the observed coefficients
(see _refine_ls_structure_factor_coef)
Y(calc) = the calculated coefficients
(see _refine_ls_structure_factor_coef)
w = the least-squares reflection weight
[1/(sigma squared)]
sigma = standard uncertainty
Nref = the number of reflections used in the refinement
Nparam = the number of refined parameters
and the sum is taken over the specified reflections
;
data_refine_ls_goodness_of_fit_ref
_name '_refine_ls_goodness_of_fit_ref'
_category refine
_type numb
_type_conditions esd
_enumeration_range 0.0:
_definition
; The least-squares goodness-of-fit parameter S for all
reflections included in the refinement, after the final cycle
of refinement. Ideally, account should be taken of parameters
restrained in the least squares. See also
_refine_ls_restrained_S_ definitions.
{ sum | w | Y(obs) - Y(calc) |^2^ | }^1/2^
S = { ----------------------------------- }
{ Nref - Nparam }
Y(obs) = the observed coefficients
(see _refine_ls_structure_factor_coef)
Y(calc) = the calculated coefficients
(see _refine_ls_structure_factor_coef)
w = the least-squares reflection weight
[1/(sigma squared)]
sigma = standard uncertainty
Nref = the number of reflections used in the refinement
Nparam = the number of refined parameters
and the sum is taken over the specified reflections
;
data_refine_ls_R_factor_gt
_name '_refine_ls_R_factor_gt'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; Residual factor for the reflections (with number given by
_reflns_number_gt) judged significantly intense (i.e. satisfying
the threshold specified by _reflns_threshold_expression)
and included in the refinement. The reflections also satisfy
the resolution limits established by _refine_ls_d_res_high and
_refine_ls_d_res_low. This is the conventional R
factor. See also _refine_ls_wR_factor_ definitions.
sum | F(obs) - F(calc) |
R = ------------------------
sum | F(obs) |
F(obs) = the observed structure-factor amplitudes
F(calc) = the calculated structure-factor amplitudes
and the sum is taken over the specified reflections
;
data_refine_ls_restrained_S_gt
_name '_refine_ls_restrained_S_gt'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; The least-squares goodness-of-fit parameter S' for
significantly intense reflections (satisfying
_reflns_threshold_expression) after the final cycle
of least squares. This parameter explicitly includes
the restraints applied in the least-squares process.
See also _refine_ls_goodness_of_fit_ definitions.
{sum | w | Y(obs) - Y(calc) |^2^ | )^1/2^
( + sum~r~ | w~r~ | P(calc) - P(targ) |^2^ | }
S' = { -------------------------------------------------- }
{ N~ref~ + N~restr~ - N~param~ }
Y(obs) = the observed coefficients
(see _refine_ls_structure_factor_coef)
Y(calc) = the observed coefficients
(see _refine_ls_structure_factor_coef)
w = the least-squares reflection weight
[1/square of standard uncertainty (e.s.d.)]
P(calc) = the calculated restraint values
P(targ) = the target restraint values
w~r~ = the restraint weight
N~ref~ = the number of reflections used in the refinement
(see _refine_ls_number_reflns)
N~restr~ = the number of restraints
(see _refine_ls_number_restraints)
N~param~ = the number of refined parameters
(see _refine_ls_number_parameters)
sum is taken over the specified reflections
sum~r~ is taken over the restraints
;
data_refine_ls_shift/su_max
_name '_refine_ls_shift/su_max'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; The largest ratio of the final least-squares parameter
shift divided by the final standard uncertainty.
;
data_refine_ls_shift/su_mean
_name '_refine_ls_shift/su_mean'
_category refine
_type numb
_related_item '_refine_ls_shift/su_mean'
_related_purpose replace
_enumeration_range 0.0:
_definition
; The average ratio of the final least-squares parameter
shift divided by the final standard uncertainty.
;
data_refine_ls_wR_factor_gt
_name '_refine_ls_wR_factor_gt'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; Weighted residual factors for significantly intense reflections
(satisfying _reflns_threshold_expression) included in the
refinement. The reflections also satisfy the resolution
limits established by _refine_ls_d_res_high and
_refine_ls_d_res_low. See also the _refine_ls_R_factor_
definitions.
( sum | w | Y(obs) - Y(calc) |^2^ | )^1/2^
wR = ( --------------------------------- )
( sum | w Y(calc)^2^ | )
Y(obs) = the observed amplitude specified by
_refine_ls_structure_factor_coef
Y(calc) = the calculated amplitude specified by
_refine_ls_structure_factor_coef
w = the least-squares weight
and the sum is taken over the specified reflections
;
data_refine_ls_wR_factor_ref
_name '_refine_ls_wR_factor_ref'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; Weighted residual factors for all reflections included in the
refinement. The reflections also satisfy the resolution
limits established by _refine_ls_d_res_high and
_refine_ls_d_res_low. See also the _refine_ls_R_factor_
definitions.
( sum | w | Y(obs) - Y(calc) |^2^ | )^1/2^
wR = ( --------------------------------- )
( sum | w Y(calc)^2^ | )
Y(obs) = the observed amplitude specified by
_refine_ls_structure_factor_coef
Y(calc) = the calculated amplitude specified by
_refine_ls_structure_factor_coef
w = the least-squares weight
and the sum is taken over the specified reflections
;
data_refln_include_status
_name '_refln_include_status'
_category refln
_type char
_list yes
_list_reference '_refln_index_'
loop_
_enumeration
_enumeration_detail
o
; satisfies _refine_ls_d_res_high
satisfies _refine_ls_d_res_low
exceeds _reflns_threshold_expression
;
<
; satisfies _refine_ls_d_res_high
satisfies _refine_ls_d_res_low
does not exceed
_reflns_threshold_expression
;
- 'systematically absent reflection'
x 'unreliable measurement -- not used'
h 'does not satisfy _refine_ls_d_res_high'
l 'does not satisfy _refine_ls_d_res_low'
_enumeration_default o
_definition
; Classification of a reflection so as to indicate its status with
respect to inclusion in refinement and calculation of R factors.
;
data_reflns_number_Friedel
_name '_reflns_number_Friedel'
_category reflns
_type numb
_enumeration_range 0:
_definition
; The number of Friedel equivalent reflections in the _refln_
list. Friedel equivalent reflections may be treated as
independent reflections in the least-squares refinement
because, although related by symmetry, they may differ in
intensity owing to inelastic scattering.
;
data_reflns_number_gt
_name '_reflns_number_gt'
_category reflns
_type numb
_enumeration_range 0:
_definition
; The number of reflections in the _refln_ list (not the
_diffrn_refln_ list) that are significantly intense,
satisfying the criterion specified by
_reflns_threshold_expression. They may include Friedel
equivalent reflections according to the nature of the
structure and the procedures used. The item
_reflns_special_details describes the reflection data.
;
data_reflns_threshold_expression
_name '_reflns_threshold_expression'
_category reflns
_type char
_example 'I>2\s(I)'
_definition
; The threshold, based on multiples of \s(I), \s(F^2^) or \s(F),
that serves to identify significantly intense reflections,
the number of which is given by _reflns_number_gt. These
reflections are used in the calculation of
_refine_ls_R_factor_gt.
;
data_reflns_shell_meanI_over_sigI_gt
_name '_reflns_shell_meanI_over_sigI_gt'
_category reflns_shell
_type numb
_list yes
_definition
; The ratio of the mean of the intensities of the significantly
intense reflections (see _reflns_threshold_expression) in
this shell to the mean of the standard uncertainties of the
intensities of the significantly intense reflections in the
resolution shell.
;
data_reflns_shell_number_measured_gt
_name '_reflns_shell_number_measured_gt'
_category reflns_shell
_type numb
_list yes
_definition
; The number of significantly intense reflections
(see _reflns_threshold_expression) measured for this
resolution shell.
;
data_reflns_shell_number_unique_gt
_name '_reflns_shell_number_unique_gt'
_category reflns_shell
_type numb
_list yes
_enumeration_range 0:
_definition
; The total number of significantly intense reflections
(see _reflns_threshold_expression) which are
symmetrically unique after merging for this resolution shell.
;
data_reflns_shell_percent_possible_gt
_name '_reflns_shell_percent_possible_gt'
_category reflns_shell
_type numb
_list yes
_enumeration_range 0.0:
_definition
; The percentage of geometrically possible reflections
represented by significantly intense reflections
(see _reflns_threshold_expression) measured for this
resolution shell.
;
data_reflns_shell_Rmerge_F_gt
_name '_reflns_shell_Rmerge_F_gt'
_category reflns_shell
_type numb
_list yes
_enumeration_range 0.0:
_definition
; The value of Rmerge(F) for significantly intense reflections
(see _reflns_threshold_expression) in a given shell.
sum~i~ ( sum~j~ | F~j~ - <F> | )
Rmerge(F) = --------------------------------
sum~i~ ( sum~j~ <F> )
F~j~ = the amplitude of the jth observation of reflection i
<F> = the mean of the amplitudes of all observations of
reflection i
sum~i~ is taken over all reflections
sum~j~ is taken over all observations of each reflection.
;
data_reflns_shell_Rmerge_I_gt
_name '_reflns_shell_Rmerge_I_gt'
_category reflns_shell
_type numb
_list yes
_enumeration_range 0.0:
_definition
; The value of Rmerge(I) for significantly intense reflections
(see _reflns_threshold_expression) in a given shell.
sum~i~ ( sum~j~ | I~j~ - <I> | )
Rmerge(I) = --------------------------------
sum~i~ ( sum~j~ <I> )
I~j~ = the intensity of the jth observation of reflection i
<I> = the mean of the intensities of all observations of
reflection i
sum~i~ is taken over all reflections
sum~j~ is taken over all observations of each reflection.
;
##############################################################################
- Prev by Date: (75) mmCIF Workshop; imgCIF/CBF Workshop; review of COMCIFS
- Next by Date: (77) Core extensions; mmCIF; absolute structure; multipole coeffs; DDL
- Index(es):