[NeXus-tech] Telco Summary
Mark Koennecke
Mark.Koennecke at psi.ch
Thu Jan 23 15:25:59 GMT 2014
============================
NeXus Telco Summary Week 04/2014
============================
Publications
===============
In the run up to the teleconference Herbert and I briefly
discussed a new publication to be written for NeXus. The last
referrable one is from 2005. Options include:
- If we have a PX application definition, there definitly should be
an article in Acta Cryst.
- Otherwise Herbert suggested to use Review of Scientific Instruments
To be continued. Any further options anyone? Journal of Instruments
and Methods comes to my mind.
AXIS Type for Fields
=======================
This is about assigning a type to an SDS such that the presence of
certain attributes can be validated. The use case is the axis type
which needs to have the transformation_type, vector, offset and
depends_on attributes.
Freddie suggested to denote axis in NXDL rather with the tag
<axis> </axis> rather then <field type="axis"</field>. To be
verified with Pete Jemian.
PX Application Definition
===========================
The rest of the time was spent on discussing the PX application definition.
The first topic were the pose:NXcollection groups. They deviate from
the normal NeXus usage. The meaning of them is to contain a list of axes
to position the component. For PX two are needed: to position the detector
and to position the sample. There is aggreement that this information
needs to
be stored.
We settled for storing the axes for the sample in a NXgoniometer group,
the ones for the detector in the detector group.
Next we went through Tobias list of issues about the PX definition:
Check that arrays are not flipped or rotated
This is about storage order of arrays. Turned out to be
very difficult to test without equipment requiring this feature.
Postponed.
Graeme will go through a test cycle which involves converting CBGF files
to NeXus and back again to CIF. Those will then be processed. If this works
we have proven that our NeXus application definition for PX is coomplete
enough.
Offset conflict
===================
Something I noted on the Telco but did not mention because I did not
want to
open a new topic: we have a conflict about the offset attribute for fields
in NeXus. There are two meanings:
- offset is Rank values of offsets to use for each dimension if the data is
not in C storage order. Of type NX_INT. This at design#attributes
- In the discussion on NeXus coordinate systems offset means: 3 float
components to describe a translation to be applied before applying
the operation
of the real axis.
Obviously this must be resolved. We agreed to rename the offset for data
not in C
storage order to data_offset.
Topics Still Pending
=======================
Variants and ESD
-------------------
Many people at the Telco liked Pete Jemians idea about specifying the
names of error fields in an attribute. Concerning variants a mix of the
different proposals was preferred. Tobias will provide an example
file with an implementation for us to look at and discuss again.
Still pending.
NXpinhole and NXslit
-----------------------
Tobias clarifies a point on this with Eugen and will prepare for voting
when
there is time available.
Eugens Proposal on Non Standard Fields
-----------------------------------------
What to we do with it?
NeXus Interfaces
--------------------
Do we want this? To be discussed later in 2014 when PX is done with.
Next Telcos
============
The next Telco is aimed for february, 5. We aim for a joint Telco together
with COMCIF in week 9; february 24-28 .
More information about the NeXus-tech
mailing list