NXxas refactoring

[woutdenolf]

WIP: everything will be moved to contributed_definitions once this is up for review.

Contributing: PR to the main branch of https://github.com/XraySpectroscopy/nexus_definitions (merge commits will be removed regularly).

Rendering: https://hdf5.gitlab-pages.esrf.fr/nexus/nxxas/classes/applications/NXxas_new.html

Example files: https://pynxxas.readthedocs.io/

NXDL questions:

- how to re-use an enum
- when enum field X has a specific value, make field Y required OR how to define enum properties
- possibly link to
- how to make a field required in a base class

[lukaspie]

Hi @woutdenolf, I came across this PR by chance and noticed that you are working on a base class for describing an electron level. In the context of photoemission spectroscopy, we in FAIRmat have also been working on something very similar: https://github.com/FAIRmat-NFDI/nexus_definitions/blob/fairmat/contributed_definitions/NXelectron_level.nxdl.xml. In fact, some of the base class we developed was originally adapated from another XAS-related PR: #1293. Would you be open to harmonizing the concept that we were developing with your approach here? I think the two approaches are already very similar right now.

[woutdenolf]

@lukaspie Yes since we are doing the same thing we should try to converge. We are currently discussing this very topic: XraySpectroscopy#2. Feel free to get involved.

The XAS working group will work in https://github.com/XraySpectroscopy/nexus_definitions. It would be helpful to add comments in that repo. This PR will be a draft and is subject to lots of changes until we are finished.

[lukaspie]

@woutdenolf great, thanks for the pointers. I will add some comments there.

[woutdenolf]

another XAS-related PR: #1293

This was the first attempt before we created the XAS working group. It will most likely be closed.

[whs92]

@woutdenolf after asking a question to the nexus mailing list and reading:

#1011
#1293

I arrived here :)

I have had a look at the proposal you made to the NXxas_new

I am particularly interested in the topic raised in #1011 of adding the ability to work with multiple detectors. I see that you've added the entry intensity that is still tied to a single mode (TFY, PFY, TEY etc). How might I add other signals acquired at the same time? How might I add more than one PFY signal?

Do you plan to include the suggestions from @padraic-shafer in https://github.com/padraic-shafer/definitions/blob/1011-multixas/contributed_definitions/NXmultixas.nxdl.xml

When is the next planned meeting of the working group? Can I come along?

[woutdenolf]

Currently we only support a single XAS spectrum. I'm very much open to support multi-detector and/or multi-scan. You are very welcome to join the XAS working group. I'll contact you directly.

[benajamin]

If you want to allow the "electron energy loss" mode, then you should also allow an "electron" probe type.

[benajamin]

What if I want to do a scan that includes multiple absorption edges (e.g. Carbon K-edge and K L-edge)? Can I specify multiple elements?

[benajamin]

Does this include Auger electron yield? Can we include a way to specify the observed electron energy range? Or should that be a detail for NXdetector?

[benajamin]

The i0 should have a corresponding NXmonitor group. There are also many ways of measuring an i0 that is useful to document in the file. For example, is the i0 measured in parallel with the sample absorption (or its proxy), or is it measured in sequence (e.g. before or after the sample), or is it sequential, but interleaved?

There is also question of how "clean" the i0 data is, as in how directly/accurately does the i0 measurement follow the ideal incident flux signal? This issue is particularly significant for C K-edge measurements - one can read my article on the topic to further understand this issue.

[ounsy]

#1352 (comment)
@whs92
@woutdenolf
I also got a request for that from one of our beamlines at SOLEIL

[mretegan]

Hi all,

@DanPorter thanks a lot for providing the formatted files. I don't think we discussed using this definition to describe XMCD, or any other type of dichroic measurements for that matter. I would be more in favor of not adding too much initially so that we have something finished for XAS; this has already taken more time than expected. This week I can update the definition with the information from the modes

Regarding the “calculated” field, it is meant to indicate whether the data is from a theoretical calculation, so its description could be improved.

[woutdenolf]

@phyy-nx @sanbrock Question for the NIAC:

XAS has several variations. The new XAS definition will only cover the variations that can be expressed as "mu-versus-energy" (transmission, total fluorescence, partial fluorescence, HERFD, etc.).

The people who create the HDF5 file need to specify which mode was used so we know what mu represents. Some modes have required metadata fields which others do not have. How can we do this in NeXus?

Some options that were suggested by the participants of the working group:

1. Extend a different application definition from NXxas for each mode: NXxastrans, NXtfy, NXherfd, NXherfd, etc. (there are currently 15 of them). Several of them will not add any new fields so they would solely exist for the purposes of providing meaning the the "mu" field.

2. The NXxas application definitions has a group called "mode" which could have several base classes as type: NXxastrans, NXtfy, NXherfd, NXherfd, etc. Remark: currently NeXus does not support an enumeration of group types in application definitions. Also it means we would create based classes with fields like "emission_lines". Several of them will be empty though and would solely exist for the purposes of providing meaning the the "mu" field which is not even in the base class.

3. Find a way for a field to become required depending on the value of another field (a string enumeration in the case called "mode"). So if for example mode="PFY" the field "emission_lines" would become required.

[woutdenolf]

NeXus has a "choice" mechanism we could perhaps be used, assuming we enforce one single mode per XAS:

definitions/base_classes/NXdetector.nxdl.xml

Line 906 in 5a44a07

<choice name="pixel_shape">

.