Proposal: NXsubsystem

[benajamin]

I attended the recent HELPMI workshop, where a community researching (visible) laser-plasma interactions discussed their needs and desires for the adoption of a common data format. One question was whether NeXus could have some way to group together sets of object being described in NXinstrument. I think we should consider making a new base class that provides such functionality that could be called NXsubsystem.

The physics of X-rays, neutrons and muons means that the devices to manipulate them tend to be of limited efficiency, which forces corresponding beamlines to have only a few components that are arranged in a somewhat straight line. Visible light beams, however, have very high efficiency optical devices, which allows experiments with such beams to have a much larger number of components in complicated arrangements (often collapsed into a restricted footprint). In the flat hierarchy of NXinstrument, it would be difficult for a human to make sense of a large number of components without either a careful naming scheme, or spending a lot of time to examine the details.

The proposed NXsubsystem base class would simply act to group instrument components together. It would contain two fields in addition to whichever base classes represent the grouped devices:

1. label: a short string representing the set (that is less restricted than the instance name, e.g. doesn't need to be ascii).
2. description: text describing the set of components.

[mkoennecke]

I wonder if these different subsystems represent different instruments and thus would be covered by NXsubentry.

[phyy-nx]

Also, how would the connections between them be expressed? Presumably a light path can be traced from one subsystem to another? That would imply an ordered dependency chain, similar to the depends_on syntax in NXtransformations, ya?

[benajamin]

@mkoennecke: These subsystems involve multiple components achieving a single collective function such as collimating or monochromating a beam. They would typically be part of a single instrument and so NXsubentry wouldn't be applicable.

@phyy-nx: I agree that describing the sequence of devices encountered by the beam is something that NeXus is currently missing and would profit from including. Something similar to the depends_on could work, though it would need to allow the beam to be split and merged. I suppose it would make sense to start at the source and point to the next component(s) downstream, however, to avoid making it complicated to trace the path backwards, we might wish to state the components in both directions.