Telco 20250716¶
Date¶
Wednesday, 16th Jul, 15:00 UTC
Connect¶
ZOOM VC link: `https://hu-berlin.zoom.us/j/65272091306?pwd=WUxEa0ZtVXp1ZHlsSlVjU2lmclMrQT09 <https://hu-berlin.zoom.us/j/65272091306?pwd=WUxEa0ZtVXp1ZHlsSlVjU2lmclMrQT09)_
Meeting ID: 652 7209 1306
Passcode: nexus
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!