FAIRmat 2024: small additions to NXsource

[lukaspie]

This PR makes some changes to NXsource, mostly to expand the range of where it can be used and to what detail the source can be described:

• class docstring: indicate that NXsource is for any kind of radiation source, not just for neutron or x-ray storage ring/facilities
• add new items to enum types: LED, Laser, etc. with the possibility to specify type_other through an attribute on type
  • this is a direct follow-up to the docstring change indicated above
• add new item to enum for probe: photon
  • this is for experiments where e.g. the X-ray energy is scanned across a wide range, such that it is neither just x-ray or ultraviolet. Think survey scans in XPS as an example.
• add new unnamed groups: NXaperture, NXdeflector, NXlens_em (see discussion below), NXfabrication
  • these are either used to describe the inner parts of the source or the way it was fabricated
  • note that NXfabrication is a new base class, but it was already approved with Fairmat 2024: actuators and sensors in NXenvironment #1414 (see vote in NXenvironment #1451 (comment))
• add new fields: wavelength, pulse_energy, peak_power, anode_material, filament_current, emission_current, gas_pressure,
  previous_source
  • these are additional parameters that can be measured on different source types during operation (see discussion below)
  • previous source: this is to be used if multiple sources are placed right after another to describe for a secondary source the instance(s) of NXsource from which a beam originated to reach this source.

[phyy-nx]

Proposal: accept changes with additions requested. Cannot merge until NXlens_em is reviewed.

Accepted by vote in NIAC2024

[phyy-nx]

@sanbrock @lukaspie the above comment says 'Cannot merge until NXlens_em is reviewed.'. What PR was that referring to?

Also there is an unresolved comment about moving some of this to subclasses.

Also, please add a description to the top of this PR. Thanks!

[lukaspie]

@sanbrock @lukaspie the above comment says 'Cannot merge until NXlens_em is reviewed.'. What PR was that referring to?

In NXsource, we are now making use of NXlens_em, which so far has been living in contributed_definitions. In order for this to be standardized, during the NIAC meeting the suggestion was that we move it to base_classes, because an officially accepted base class should not depend on a contributed one. However, this can also be done in a separate PR if you agree.

Note that in our current implementation, NXlens_em is inheriting from the much broader NXcomponent. It would probably be helpful to discuss whether this is a good idea and, if so, NXcomponent should also be standardized.

Also there is an unresolved comment about moving some of this to subclasses.

Here, I am a bit stumped as to what the idea was. I discussed it a bit above in the comment itself.

Also, please add a description to the top of this PR. Thanks!

Done.

[phyy-nx]

Comments from Telco:

• Remove type_other and Other from the type enumeration
• Create a new PR that adds to enumeration an attribute open=False, which would allow the enumeration to allow values not in the list. Note that accepting that change would require adapting sphinx to render it nicely, and affect validators. They should not produce errors but could produce a warning. That PR would need a NIAC vote.
• Don't go with subclasses for wavelength, gas_pressure, etc. Not technically what we voted on, but the Telco agrees that we'd have to do mixed inheritance which isn't technically possible given our new inheritance model.
• Remove NXlens_em. When NXlens_em is approved to move out of contributed definitions, in the same PR that implements that, NXlens_em can be re-added to NXsource

Once the above is done, a simple review and merge can be done. No vote needed.

[phyy-nx]

Whoops, this one didn't need a vote. Comment deleted

[lukaspie]

Thanks @phyy-nx for resolving and merging!