[Nexus] Multiparametric acquisitions

[V. Armando Solé]

On 30/10/2015 15:06, Koennecke Mark (PSI) wrote:
> 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:
>> 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?

To me just to add the possibility to have the interpretation attribute 
to be "extended" to its "timed_XXXX" equivalents would be the first step 
to say that for instance, one image has been taken at a particular 
time.  Then the problem comes about how to represent the associated 
time. The most generic way would be to use an additional dataset in the 
relevant NXdetector at the same hierarchical level as the data. My 
original idea of having time stamped images as [time_stamp, row, column] 
face the problem of having to use the same representation for the 
detector contents and the time thus leading to probably longer files 
than needed to achieve enough precision.

Other possibility would be to add a new attribute "time_stamp" with the 
name/path of the dataset containing the time. Probably this is the 
solution that is closer to Nexus philosophy.


>>  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?
>

I am not an expert. In some cases one has a external clock with one 
device able to collect data at each clock pulse, other one on each 10 
clock pulses and so on. In other cases just the system EPOCH... One 
could also imagine detectors triggered regularly by a clock working 
together with detectors in event mode.

What is clear is that we have to find a way to represent those data.

Armando