search

nexusformat / definitions

Definitions of the NeXus Standard File Structure and Contents
https://manual.nexusformat.org/
Other
26 stars 57 forks source link

Scanning experiment with NXfluo #933

Open neitmedia opened 3 years ago

neitmedia commented 3 years ago

According to https://www.nexusformat.org/Update_for_NXflou_application_definition.html it should be possible to store scanned data in the NXfluo structure.

As far as I can see the NXfluo.nxdl still requires data fields with a rank of 1. Is it possible to use the NXfluo application definition to store fluorescence data from scans?

If I store the data according to https://www.nexusformat.org/Update_for_NXflou_application_definition.html nxvalidate throws an error.

prjemian commented 3 years ago

The NXfluo NXDL needs to be revised so that use with additional dimensions is supported and obvious. Other application definitions might also need this revision.

benajamin commented 3 years ago

Perhaps you could provide more detail on what you mean by "scan"? If you are doing 2D scans (measuring the fluorescence at each point), you might also find other application definitions like NXstxm to be useful.

neitmedia commented 3 years ago

In our use case, different measurements are made in one 2D scan. Specifically, this involves STXM and fluorescence measurements. My approach was to use a subentry "NXstxm" and a subentry "NXfluo" for each scan. With NXstxm there are no problems so far, only with NXfluo I currently reach my limits.

So am I right in assuming that it is standard-compliant to use NXfluo for a scanning experiment for our use case, even if this cannot be validated correctly at the moment?

I know that I could use NXstxm, but I want to stick to the existing application definitions as far as it is possible. Or do you think that NXstxm is also the right application definition for fluorescence measurements?

benajamin commented 3 years ago

In short, I recommend using NXstxm for the fluorescence data since it will simplify your files and is just as standard-compliant as the alternative with multiple subentries.

Although we make an effort to be consistent across all of NeXus, the application definitions are essentially their own implementation of the format. NXfluo was one of the earlier ones written and so is a bit on the simple side. There is a general strategy to adding scanning to such simple application definitions like NXfluo, but we haven't formally expressed it. I wrote NXstxm to adapt the general NeXus scanning strategies to the specific case of STXM (which is still fairly general in most respects), so extending NXfluo to include scanning is going to look very similar to NXstxm. The use of subentries is recommended for combining application definitions that are not easily compatible, but I think they should be regarded as a "last resort" when you can't fit everything into a single application definition. Therefore, I would recommend that you just use NXstxm and include the fluorescence data by adding an extra NXdetector (in NXinstrument) and a corresponding extra NXdata.

neitmedia commented 3 years ago

Thank you for the clarification. For our application, I will include the fluorescence data into the NXstxm structure.