search

FAIRmat-NFDI / nexus_definitions

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

NXdata derived base classes not recognized as NXdata #233

Closed rettigl closed 1 month ago

rettigl commented 1 month ago

Base classes "inherited" from NXdata, e.g. NXdata_mpes, are not being recognized by Nomad/h5web as NXdata groups, and are not being properly displayed (see missing nx symbol). image

@lukaspie @domna

lukaspie commented 1 month ago

This is a known problem coming from this line: https://github.com/domna/h5web/blob/524eab54543d09611db07d22495d7b2b4f67a475/packages/app/src/vis-packs/nexus/utils.ts#L36, which basically just checks for NXdata and not if there is any extension of NXdata.

This is why we temporarily deactivated the use of NXdata_mpes in NXmpes: https://github.com/FAIRmat-NFDI/nexus_definitions/pull/214. I guess you are still using it in NXmpes_arpes, right? That being said, we should probably just talk to the H5web developers so they can implement this for us.

lukaspie commented 1 month ago

Since extensions of base classes is currently not yet supported by NIAC, I am however not sure how readily the H5web devs will implement this feature (or accept it if we choose to implement it).

rettigl commented 1 month ago

This is a known problem coming from this line: https://github.com/domna/h5web/blob/524eab54543d09611db07d22495d7b2b4f67a475/packages/app/src/vis-packs/nexus/utils.ts#L36, which basically just checks for NXdata and not if there is any extension of NXdata.

This completely slipped my mind. Yes, then let's keep this for now as it is, and fix NXmpes_arpes accordingly. @lukaspie can you do this?

lukaspie commented 1 month ago

https://github.com/FAIRmat-NFDI/nexus_definitions/pull/236

domna commented 1 month ago

There are also additional problems when extending NXdata I only recently understood. There are many special cases which are just valid in the context of NXdata, e.g., there are two variadic concepts AXISNAME and DATA which cannot be resolved just by namefitting. Therefore, NXdata has the speciality to associate the names stored in @axes and @signal to either AXISNAME or DATA. Generally, we also remove a name we specify in the appdef (i.e., energy) from a concept such as DATA or AXISNAME, because we have no mechanism in nexus to tell that this name belongs to the concept AXISNAME or DATA (as this is normally associated by namefitting). In the current validation I actually overwrite the concept association if the name is found in @signal or @axes but it means that, e.g., energy is not specified as an AXISNAME on appdef level but the associated depends of what users write in their @axes array.

This means that there is a dynamic association of concepts based on the found data. This is special to NXdata and we would need to inherit these specialities as well but it also means that our process of creating NXdata_mpes by just copying the field does not work (except we would use the convention that NXdata_.... inherits the specialities of NXdata). If we have base class inheritance we could also just inherit the specialities of NXdata.

domna commented 1 month ago

I see there is a way of associated a concept in NXdata by requiring it in NXdata/@axes as done here: https://github.com/FAIRmat-NFDI/nexus_definitions/pull/236/files#r1625689878

However, I'm not sure if this is completely supported by nexus the way it's done there.