[Nexus] Motors
Pete Jemian
prjemian at gmail.com
Thu Dec 16 12:04:26 GMT 2010
+1
-----Original Message-----
From: "V. Armando Solé" <sole at esrf.fr>
Sent: Thursday, 16 December, 2010 4:06 AM
To: nexus at nexusformat.org
Subject: Re: [Nexus] Motors
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
_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus
More information about the NeXus
mailing list