[NeXus-committee] RFC variants and esd
Mark Koennecke
Mark.Koennecke at psi.ch
Thu Oct 24 13:56:33 BST 2013
Request for Comments
=======================
There are two topics on which we seek comments from the wider
NIAC. Both issues arose from the discussion about the CIF-NeXus
mapping and a MX application definition in collaboration with the
CIF group. The issues were discussed at length at various NeXus
teleconferences. Now we seek comments from the wider NIAC in
preparation for a proposal to vote on.
Variants
-------------
The problem: there are parameters in a NeXus file for which better
values may become available later on through a refinement, calibration
or whatever. The requirement is to store both the old and the new value
together with a time stamp. Variants are required for a full mapping
of CIF concepts to NeXus. The experience of the CIF people is that
variants will be used only occasionally and only for a few fields.
Thus a heavy weight scheme for handling this situation is not necessary.
The suggestion: Apply the following process when a new value is available
for an existing field in an NeXus file:
1) memorize the current value
2) Update the field and assign a time_stamp attribute to it.
3) Store the old value in a new field with a name derived by appending
_variant to the original field name. Assign a time_stamp attribute
to this
new field too.
When more then one variant is required, build names by appending
_variant_somename
, _variant_someothername to the original field name.
An example:
wavelength
@time_stamp=sometime
wavelength_variant
@time_stamp=someothertime
A more elaborate example:
wavelength
@time_stamp=sometime
wavelength_variant_asdialled
@time_stamp=someothertime
wavelength_variant_fromSI
@time_stamp=someothertime
Discussion
------------
We considered using a variant attribute to the field. But this causes
problems
when a larger field, like for example an area detector efficiency
correction,
needs a variant. It is also non obvious how to store the time stamp then.
We are aware of the fact that the suggested scheme can lead to long names.
We rely on the fact that the CIF experience is that variants are rarely
used.
And CIF has been around for a while. Reading software only needs to concern
itself with the real field name which is supposed to hold the best
available
value.
Standard Deviation
----------------------
The problem: Real physical values have errors. NeXus accounted for this by
having fields with _error appended for a few fields. The reqirement now is
to have a standard scheme for marking up experimental errors for any field.
The suggestion: store the errors of a field value in a new field. The name
of this field is derived from the original field name by appending _esd to
it. Example:
wavelength
wavelength_esd
Please let us know what you think. Other suggestions, even completely
different
ones, are very welcome. The only requirement is that the suggestion
offers a
solution to the original problem.
Best Regards,
Mark Koennecke
More information about the NeXus-committee
mailing list