[NeXus-tech] todays telecon

Wed Jul 10 13:59:10 BST 2013

On 07/10/2013 02:40 PM, Tobias.Richter at diamond.ac.uk wrote:
> I am joined by Freddie now...
>
> -----Original Message-----
> From: nexus-tech-bounces at nexusformat.org [mailto:nexus-tech-bounces at nexusformat.org] On Behalf Of Peterson, Peter F.
> Sent: 10 July 2013 13:38
> To: NeXus Technical sub-committee list; yayahjb
> Subject: Re: [NeXus-tech] todays telecon
>
> Sorry about this. There is *now* a conference call setup to join if people are still interested.
>
> On 7/10/13 8:32 AM, "Wintersberger, Eugen" <eugen.wintersberger at desy.de>
> wrote:
>
>> Hi all
>>   just wanted to write that there is no conference set up ;) My skype
>> account is: eugenwintersberger
>>
>> cu
>>
>> On Wed, 2013-07-10 at 08:30 -0400, yayahjb wrote:
>>> The ORNL operator does not have the conference set up.  I you all
>>> have Skype, we can do a Skype group call.
>>>
>>>
>>> On 7/10/13 8:13 AM, Wintersberger, Eugen wrote:
>>>> No,  I did not receive one. Neither did Tobias. Have you got a
>>>> notification?
>>>>
>>>> regards
>>>>     Eugen
>>>>
>>>> On Wed, 2013-07-10 at 13:05 +0200, Mark Koennecke wrote:
>>>>     
>>>>> Eugen,
>>>>>
>>>>> I thought I asked Peter to do one. Has there been no notification?
>>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>> On 07/10/2013 12:34 PM, Wintersberger, Eugen wrote:
>>>>>       
>>>>>> Hi folks
>>>>>>     has someone made a registration for todays telecon at ORNL?
>>>>>>
>>>>>> regards
>>>>>>      Eugen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> NeXus-tech mailing list
>>>>>> NeXus-tech at nexusformat.org
>>>>>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>>>>>>         
>>>>> _______________________________________________
>>>>> NeXus-tech mailing list
>>>>> NeXus-tech at nexusformat.org
>>>>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>>>>>       
>>>>     
>>>>
>>>>
>>>> _______________________________________________
>>>> NeXus-tech mailing list
>>>> NeXus-tech at nexusformat.org
>>>> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>>>>     
>
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>

-------------- next part --------------

Concordance Summary
--------------------

May, 23, 2013, Mark Koennecke

This document summarizes the problems occurring when mapping CBF to 
NeXus how I see them from the discussion with Herbert. In the following 
discussion all groups which are not NeXus yet will be prefixed with 
TBD for To Be Discussed. This is the version updated after the May, 22 
teleconference. 

The Variant Issue
----------------------

CBF has the concept of variants for fields. For example there is 
a field beam_center_x. This has somehow been determined and written 
to file. Later this is refined in another way. CBF stores this then 
as beam_center_x_variant. This concept of variants is missing in NeXus.
Another way to understand this is to see it as a version control for 
values. However, as this is rarely used, a complicated solution is not
desirable. 

So far there are three options to remedy this:

- A TBDvariant group which can occur in all other groups and 
  contains the variant values with the same field names as in the 
  parent group.
- Simply append _variant to the existing NeXus name. If there is more 
  then one variant append another qualifier to _variant. For example:
  beam_center_x_variant_refined
- As the request can rather be understood as  a means to keep track of old 
  versions of values, another option is this rule: When updating a value, 
  update the value with the NeXus name. Store the old value in a new field 
  labelled with nexusname_old_timestamp. Where nexusname is the original 
  name of the filed, for example beam_center_x, and timestamp is a: timestamp 
  like 2013-05-23. At the Telco, this was the preferred solution. 

The Axisset Issue
--------------------

NeXus chooses to document axis names with a predefined meanings. The 
CBF people learned that this did not work for them as people were using 
axes differently, could not be bothered to even look which conventions 
others used etc. Thus they choose rather to document axes by the 
way how they operate. And a given component may even have more then 
one axes description associated with it. 

NeXus goes a long way to support this with the recently added offset, type, 
vector and depends_on attributes. 

But mapping the full CBF scheme would require a TBDaxisset group which can 
occur in any component which we care to place (sample, detector,...) This 
group could look like this:

TBDaxisset
   axis-name-or-id[NA]
   offset[3,NA]
   type[NA]
   vector[3,NA]
   depends_on[NA]

with NA being the number of axes. 

I can see that such a scheme would also allow NeXus to neatly describe 
a given data set in terms of different axis types: instrument coordinates, 
q coordinates or whatever.

At the Telco the agreement was that the current NeXus scheme is sufficient 
to do the CBF mapping. But for further use, it might be a good idea to 
reserve the namespace for axisset. It was also felt that there to many 
ways to describe axes in NeXus and we should discuss and aggree on a 
preferred way to do axes in an upcoming NIAC meeting. 

The Scan Issue
------------------

NeXus chooses to store scans as it is done, with the positions of components
as read from the hardware in arrays. CBF chooses to rather store the intent 
of the scan: i.e. the axis moved, their start and increments etc. NeXus 
lacks such a intent description. This already caused us problems because the 
intent axes are nice for plotting and the actual positions as read are 
necessary for detailed DA. 

Thus to capture the CBF description a new group may be required:

TBDscan_intent
   axis-name-or-id[NSA]
   start[NSA]
   increment[NSA]
   NP

with NSA being the Number of Scan Axes and NP the number of points in 
the scan. May be some more fields. 

The agreement on the NeXus Telco was that the recently aggreed upon 
axes scheme with the attributes on the NX group is sufficient to do 
the CBF mapping. Again, it might be worth to reserve the namespace.

New Fields 
--------------

This may be a bit easier: the CBF mapping asks for a couple of fields to 
be added to the NeXus base classes:

NXxray_tube
   radiation_type         
   radiation_xray_symbol

Radiation_type is different to probe. Probe gives a very general description 
like neutrons, x-ray etc.  This gives the type of radiation like Cu Kalpha, 
Mo etc. The situation is further complicated by the fact that even at 
synchrotrons wavelengths are selected which match the characteristics of 
well known x-ray tube anode materials. Thus, a NXxray_tube group may not 
be the appropriate place. 

NXcollimator

   div_x_y_source
   radiation_filter_edge    # May belong into a NXfilter
   radiation_inhomegeneity  # May belong into NXsource or NXmonochromator

CBF stores polarisation information of the beam in NXmonochromator. 
It is an open question where this belongs: NXbeam, NXpolariser or 
NXmonochromator being candidates. The fields:

polarisation_norm
polarisation_ratio
polarisation_source_norm
polarisation_source_ratio

NXdetector
  gain
  gain_esd
  linerarity
  offset
  scaling
  overload
  undefined_value

Some of these fields address the computed data value issue which we 
discussed some time ago. The last state on this was that Armando was 
to make a proposal for calculated data. Which, as far as I am aware, 
did not happen.   

CBF also has a structure to describe the elements of a multi component 
detector. We discussed something similar recently with the DECTRIS module
. This was then added a s a non NeXus standard group. May be we need to 
revise this with input from CBF?

The good news is that the proposed fields come with documentation which we 
may directly copy from the CBF documents. 

NXgoniometer 
----------------

Consider the situaton when a sample is mounted on some sort of positioning 
device: x-y tables, eulerian cradle goniometer or such. The current NeXus 
convention is to store the values coming from such positioning devices in 
the NXsample group.  The rationale is that their purpose is to position 
the sample. Now, the suggestion is to separate such values out into a 
NXgoniometer group. This unloads the sample group somewhat and makes for 
a cleaner separation.  Where in the NeXus hierarchy a NXgoniometer will 
be positioned is another question to be discussed: NXsample or NXinstrument 
both being good candidates. 