Fairmat 2024: proposal on photoemission spectroscopy (MPES)

[lukaspie]

This brings in the application definition NXmpes together with its specialization NXmpes_arpes and NXxps and related new base classes.

NXmpes is designed to be the "umbrella" application definition for multi-dimensional photoemission spectroscopy (this is what we call MPES). NXmpes has been incubating in the contributed definitions for more than xx years now and has been heavily tested within the communits. We (as FAIRmat) also organized two workshops with technology partners (i.e., companies building photoemission spectroscopy setups + scientists from the community) to come to a community agreement. Thus, we propose to add it to the NeXus standard as an application definition.

On top of NXmpes, two specializations have been added: NXmpes_arpes (for ARPES data) and NXxps (for XPS data). These are meant to specialize/clarify the concepts in NXmpes for the specific scientific domain. In the case of XPS, the terminology closes follows that of the existing ISO standard for vocabulary in surface chemical analysis and, if applicable, makes direct links where terms are used in the same way. It also uses the community-agreed coordinate system (see ISO standard for data transfer in surface chemical analysis and #1415).

Alongside these new application definitions, there come several new base classes:

• NXelectronanalyser: for describing all components of a typical electron analyser used in such experiments
• NXcollectioncolumn: for describing the lens system of a photoemission spectroscopy setup
• NXenergydispersion, NXspindispersion: for describing the energy/spin dispersive part of the electronanalyser
• NXmanipulator: for describing the multi-axes manipulator that typically holds the sample as well as any sensors/acutators mounted on it.

Most of these were already previously part of the contributed definitions.

• NXdata_mpes, NXdata_mpes_detector: these are specializations of NXdata that contain a named set of axes that are typical for photoemission data (energy, k-space axes, momentum axes, ...). These are mostly used so that the application definition does not get too big, but rather the concepts are defined in the specialized base classes.

• NXelectron_level: there are a number of specialized NXprocess options available in NXmpes. One of these is about the energy calibration w.r.t. another electronic level in the spectrum (as used in XPS). NXelectron_level allows for a description of such levels beyond a simple string notation.

• NXfit, NXpeak, NXfit_background, NXfit_function: these are all used for describing a fit to a dataset. In XPS specifically, they are used to define a peak model (consisting of multiple fits to the data). They are meant as a rigorous description of the procedures, data models, and constraint used in such fitting operations. Note that here, we don't use any formulas, but rather formula_description, in line with what was discussed in the NIAC meeting 2024 (see discussion here: Math support in NeXus #711 (comment)).

In addition to these base classes that are specificly discussed above, this PR contains many more additional new base classes and changes to existing base classes. Most of these have been discussed already, but the PRs are not yet merged. Note that these changes have already been brought to this branch right here to make the CI/CD pass (as several new base classes also depend on each other). Eventually, it is expected that oncee these PRs are finalized and this branch has been rebased, this PR here will be much smaller. Specifically, this PR depends on #1408, #1409, #1410, #1413, #1414, #1415, #1419, #1420. For a full list of (inter)dependencies, see discussion here: #1464 (comment).

[rayosborn]

This PR wants to create more than a dozen new base classes, along with major changes to several more, and yet there is minimal description of why they are needed and the links to other issues or other PRs provide little additional information. IMHO, it is impossible for the NIAC to assess such a huge PR as a single entity. I would suggest that there needs to be a separate PR for each base class, new or modified, containing a detailed explanation of why the PR is needed. This will slow the process down considerably, so at the next Telco I would suggest we discuss how to handle such a backlog, e.g., by assigning a couple of members to review each one and report back with comments so that we can have an expedited discussion and vote. However, I would recommend withdrawing this PR until we have decided how to proceed.

[lukaspie]

This PR wants to create more than a dozen new base classes, along with major changes to several more, and yet there is minimal description of why they are needed and the links to other issues or other PRs provide little additional information. IMHO, it is impossible for the NIAC to assess such a huge PR as a single entity. I would suggest that there needs to be a separate PR for each base class, new or modified, containing a detailed explanation of why the PR is needed. This will slow the process down considerably, so at the next Telco I would suggest we discuss how to handle such a backlog, e.g., by assigning a couple of members to review each one and report back with comments so that we can have an expedited discussion and vote. However, I would recommend withdrawing this PR until we have decided how to proceed.

@rayosborn Thanks for the feedback. Indeed, there was a lack of description in this PR, so I added a lengthy one. I also tried to describe that this PR, while having many changes as of right now, essentially comes down to the three mentioned application definitions (two of which are specializing the other one) + a set of base classes that are essentially needed for describing these kinds of experiments. In addition, it also introduces base classes for describing fits to data (NXfit etc.). All of these base classes are heavily used within the application definitions, so I don't really see how they can be separated from that discussion here.

I agree there's a lot of changes in this PR and it can be hard to understand what is happening/changing when trying to review it. However, note that all of the other changes (as mentioned above) are already discussed elsewhere. They were brought in here for the reason that the new base classes and application definitions heavily depend on them and it would be impossible to understand these without having the other changes alongside them. Eventually, before merging, this PR can be much smaller once all of the other PRs have been finalized.

What I don't see is why the changes that are proposed here cannot be discussed now in this PR. I agree that it would make sense for a couple of NIAC members to do so, but I can't see how to make the changes here any smaller than they are right now (aside from removing everything that is discussed elsewhere, this we could do). We are open to whatever is discussed in the next Telco though, but until then, I will leave this PR open.

[phyy-nx]

@lukaspie thanks for the description and your reply.

What I don't see is why the changes that are proposed here cannot be discussed now in this PR.

It's simply because the other unmerged PRs (#1408, #1409, #1410, #1413, #1414, #1415, #1419, #1420) make this one too hard to read, that's all. Providing that list was incredibly helpful, thank you. I anticipate once those are merged and this is rebased, the review will be greatly expedited!

[phyy-nx]

Re-posting the TODO list including what I think are the dependencies:

#1408, #1409, #1410, #1413 --> #1419 and #1486, #1414, #1415, #1419 --> #1414 and #1486, #1420 --> #1419