[Nexus] Multiparametric acquisitions

[Koennecke Mark (PSI)]

Armando,

> Am 28.10.2015 um 14:15 schrieb V. Armando Solé <sole at esrf.fr>:
> 
> Hi Mark,
> 
> On 28/10/2015 13:36, Koennecke Mark (PSI) wrote:
>>> Am 28.10.2015 um 11:23 schrieb V. Armando Solé <sole at esrf.fr>:
>>> 
>>> Dear colleagues,
>>> 
>>> We have the interpretation attribute to interpret a multidimensional dataset as scalar/scaler, spectrum, image,  vertex,   and so on. However, I would like to know if there is anything foreseen for dealing with time stamped data. We are going towards acquisition systems in which each actor/detector is "throwing" data at its maximum speed without being synchronized with other actors/detectors.
>>> 
>>> Naively, I would think about keeping together the time information with the dataset (for instance dedicating one additional dimension to the time stamp in such a way as having the interpretation attribute to be allowed to take other values: "timed_scalar", "timed_spectrum", "timed_image", ...)
>>> 
>>> I know some of you are working in different "list" modes and perhaps there is something already foreseen.
>>> 
>> nice to hear from you again. What you are describing will become a topic in the near future. Until then we still have
>> NXlog to offer. Or may be NXlog is the future? So what about, storing NXlog’s instead of fields in the NeXus structure
>> where you have such time stamped data?
>> 
> 
> At this point we do not have them yet but we foresee experiments on which we'll have data flowing at at least three different speeds. At this moment we are aim to group different detectors and positioners by "timer" so that is easy to correlate/visualize/diagnose things at least on common timers. The generalization of it would is each device server writing time stamped data. To me, to allow "data" in NXdetector to contain the time information would be enough. In that sense, just to be able to extend the interpretation attribute to "timed_xxxx" where "xxxx" are the already handled cases seems to me the simplest. To use NXlog would imply that "data" for an NXdetector would become an NXlog group and that seems to me more cumbersome.
> 

OK; this is one way. But the topic needs to be raised anyway. What would be your requirements?

> From the documentation NXlog seems to foresee only one time and one value, although it could easily be generalized to arrays.
> 

I would buy the generalization to arrays.

In an other matter: for ESS we have a high quality timing system. What do you use to get all those different streams on a 
common time? Do you have access to the rings timing system?

Best Regards,

     Mark


> Best regards,
> 
> Armando
> 
> 
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus