[Nexus] Motors

["V. Armando Solé"]

Dear all,

On 16/12/2010 09:08, Mark Koennecke wrote:
> My 2c:
>
> NeXus is intended as a data exchange format and as such cares only 
> about  the most exact value of translations
> and angles at the appropriate places in the NeXus hierarchy. I 
> acknowledge the request to store additional motor
> parameters in order to debug the instrument. So this stuff ought to go 
> into a NXcollection. NeXus does not really care
> where this goes. Or should it? Is this a new requirement? Concerning 
> the linking of values to NXpositioners there are
> two options, which are equal in respect to an application definition:
> 1) you store the value at the NXpositioner and link to it from the 
> right place in the application definition.
> 2) you store the value in the application definition compliant part of 
> the NeXus hierarchy and create a link in
>   your NXpositioner
>
> I have a slight preference for 1) because then the target attribute 
> tells you where to go in order to find all the gory
> details of the motor right from within the application definition 
> hierarchy.
>
> The ideal storage for a motor would be to have a value in the NeXus 
> hierarchy which is a group at the same time
> which upon opening reveals all the other gory parameters.  Like this:
>
> entry:NXentry
>     sample:NXsample
>                  rotation_angle
>                              zero
>                              lowerlimit
>                              upperlimit
>                              cap_name
>                              .......
> This is how it looks like within SICS. But HDF does not allow this. A 
> data field cannot double as a group. And a group
> not as data.The only way we can achieve this in HDF is to use 
> attributes. This means converting all the fields of
> NXpositioner to attributes of the value stored in the NeXus hierarchy. 
> Performancewise this is no problem, we
> are talking at max two handful of parameters/attributes per motor here.
>
> Another option would be to make rotation_angle a group of type 
> NXpositioner. But I am very reluctant to
> do this as it would add yet another layer of hierarchy before getting 
> at the values. And it would require rewriting
> all the application definitions we already have.
>
> I am also a little bewildered by this discussion: at our place motors 
> are units which just work. And if not, we
> ask the electronics guys to fix them!

Beamlines change the motor parameters fairly more often then just at 
installation.

Positioners (not just motors) get programmed for a particular scan and 
their speed can change form one scan to another.
>
> In an attempt to bring this forward some questions to the community:
> -  Does NeXus need to care about where NXpositioners go?

My opinion is that it should not care about it. Common sense would place 
them somewhere inside NXinstrument but I do not see it as a requirement.

> -  And make suggestions beyond NXcollection/NXpositioner?
> -  What do people think about dropping NXpositioner and storing the 
> parameters in there as attributes
>  to a data value?

The day I learned attributes are not "updated" but "recreated" leaving 
wasted space in the file I got very disappointed about their use.

If one needs a very complete description of a motor (or a generic 
positioner like a temperature controller that can be scanned), then 
NXpositioner takes all its relevance. Personally I would not use an 
NXpositioner group to store just a float value and I would just write 
the value and the motor name inside an NXcollection just to reduce 
hierarchy. If I need to add a complete description of the positioner, 
then I would use the NXpositioner group, use the already foreseen NeXus 
fields and drop the rest inside an NXcollection group named properly 
(for instance "additional_parameters"). So, to me 
NXpositioner/NXcollection combination is fine.

Best regards,

Armando