Telco 20250716

Date

Wednesday, 16th Jul, 15:00 UTC

Connect

Agenda

  • PRs

Present

SB, AB, FdA, FS, HB, RO, PC, WdN - MarkusK, LukasP, RubelM (FAIRmat), GerritG (HMC)

Minutes

  • Computational Geometry PRs - 1421 (1532)

    • AB: vote is ongoing

  • EM - 1423 volunteers for reviewing: AB, HB

    • MK: feedbacks from Alba have been addressed. Ready for vote

    • AB: we can start the vote tomorrow

    • RO: suffix vs prefix needs to be cleaned. Eg.NXlens_em?

    • MK: yes, we can rename it to NXelectromagnetic_lens

    • AB: also modify NXscanbox_em

  • OptSpec: 1425

    • MK: PR is accepted, but still few comments to be resolved before merge

    • PC: all resolved already

    • AB: we can merge

    • LP: there were suggestion for pulling some definitions from AppDef to new Base calsses. This can be done in a PR later

  • dictionary for spellchecking the defintions

    • LP: a PR could be set up a dictionary, so we run a spell checker on definitions when building the documentation

    • AB: it is valuable, let us prepare such PR

  • PR to update contributed definitions

    • SB: FAIRmat defintions are moved to AppDef, BaseClassdes or kept in contributed, but got updated

    • AB: it is fine to merge when cleaned.

  • SECoP PR

    • GG: NeXus allows a basic mapping of SECoP data, but next to temperature, and magnetic_field, others would be needed. Eg. humidity, viscosity, concentration should also be added to NXsample and NXsensor. Multiple sensors can measure at different positions, but maybe one needs to be a dedicated one for describing the Sample state, so field in NXsample would be nice for those measurements, too.

    • MK: It would also be nice to connect these terms to external otologies, like https://www.qudt.org

    • RO: Is SECoP implemented by manufacturers?

    • GG: Pickup is in progress. Unfortunately, NeXus base classes give too much freedom in mapping these terms to NeXus fields/groups, so files from different facilities could look different although they supposed to contain the same information.

    • RO: it would be nice to have a stable documentation of the terms and definitions from SECoP

    • LP: Why do we need separate Field, next to the sensors?

    • GG: we use a softlink to the corresponding sensors’s value Field.

    • LP: This could be added to the documentaion, that a link could be used here

    • GG: Sure! Regarding ontology links, it would be needed for those sensors which are not yet defined precisely in NeXus, but we could link them to an external ontology term.

    • MK: definitions are nice that define clearly the terms. Open enumerations can be used if arbitrary new fields could be supported

    • AB: terms clearly defined in SECoP could be taken by NeXus, we need a clear definition page

    • AB: do we want to just add more and more fields, or rather we could reorganise NXsample

    • MK: exactly, unit_cell is another example in NXsample where better structure is now available compared to the original flat list of unit_cell parameters. Similar improvements could be applied to Sample Environment, too.

    • RO: Symbols here (n_comp) is incompatible with the proposed use of the fields here. Note that the use of symbols are more and more problematic when used in base classes.

    • AB: After clarifications in documentation, we could move it to a vote

  • PR 1574: FIELDNAME to NXobject (and PR 1569 - self-description for non-NeXus terms)

    • GG: @datatype (similarly to @units) could be added. @ontology_concept link would also be neede to be able to connect metadata to external defintions

    • SB: datatype is covered by hdf5 datatype (so no additional attribute is needed). Ontology links: This is supported for Groups via identifierNAME, but NIAC decided not to support it for Fields yet

    • MK: could be nice even for Attributes

    • RO: It is intentional not to support validating undefined fields.

    • LP: With this change every field becomes “defined” even if there was no real definition attached. This is a bigger change in the standard

    • SB: A PR to be considered would need more description also detailing better the impact, modification of the standard, and the new expected use (e.g. how validators would operation on new nexus field types). Discussion should continue in this PR, and when

  • NXparameter - PR 1560

    • RO: it is an improvement of the documentation with extra attributes

    • MK: NXparameters could be used for any analysis, not only for fitting, so documentation could state it clearly.

    • LP: @min, @max, etc. is all nice, but shall @model not be defined somewhere else?

    • RO: each model shall have a separate parameters group with respective parameters inside. It is good to be agnostic to analysis package, but wanted to properly cover lmfit.

    • SB: what about having a generic NXparameters, and a specialisation of NXlmfit_parameters

    • LP: NXfit_function does similar. We could harmonise e.g. names, like min/max vs. min_value/max_value, we could take your name convention.

    • RO: I can change to be compatible to NXfit_fucntion

  • NXgoniometer - PR 1561

    • RO: no NXtransformation is used here, but it would allow defining goniometer conventions (rotations, transformations)

    • PC: it does not support machine readibality. An Application Definition could specify which convention to be used and the use of this application definition would actually be machine readable, but it would be useful only together with NXtransformations.

    • RO: One can reference a paper where the convention is defined.

    • HB: Even if people may not use NXtransformations, please include how NXtransformations could be coupled with the current proposal.

    • PC: to avoid duplications, NXtransfomrations fields would use links to the here specified fields, but their attributes are in contradiction. Alternatively, NXpositioners could also be used.

    • RO: it is problematic to encode the full transformation chain in a file, because what is written may not be fully implemented on the beamline, and it results in a wrong/incorrect file.

    • HB: recording value without metadata describing its meaning is not good. Machine readable metadata is needed.

    • RO: happy to connect it to NXtransformations. Any proposals are welcome.

    • WdN: NXtransformations would look in NexPy exactly as NXgoniometer (with the exception of the required @vector).

    • SB: we could compare the two solutions visually. RO can provide demo data, and WdN could model it using NXtransformations.

    • HB: vector is needed for clarifying the handedness of the goniometer.

Aug Telco

Please help to `choose the date by responding to the poll by July 24.

We are planning to hold the telco in the regular slot of UTC 15:00. Check your local time to avoid scheduling surprises!