NIAC2026 Minutes¶
Participants:¶
NIAC in person: AB, SB, FdA, RB, HG, WdN, PM, MW, ZM, PC, RO, MO, (TM)
NIAC online: HB, BW, BB, GT
other participants:
Aaron Finke
Andre Costa
Renee Helfert
Christopher Philip Schleisinger
Celine Durniak
Erika McPhillips - SLAC
Mustafa Alzubi - SESAME
Marius Retegan - ESRF
George O’Neill - ESS
Mridul Sath - ESS
Diego Gaemperle - DECTRIS
Jonas Fortmann - ZBT
Iryna Lypova - FRM II / TUM
Jan Kotanski - DESY
Loas Kron-Batenburg - RDL IUCrData
Markus Kuehbach - FAIRmat
Rubel Mozumder - FAIRmat
Lukas Pilsticker - FAIRmat
Oleksii Turkot - EuXFEL
Paulo Mausbach - SIRIUS
Eva Lott - HZB
Peter Braun - HZB
Hector Perez Ponce - HZB
Sonal Patel - HZB
Sarah Foxley - ISIS, Mantid Team Lead (sarah.foxley@stfc.ac.uk)
Yannick Meinerzhagen - RWTH Aachen
Meghdad Yazdi - MAX IV
Jeremy Metz - MAX IV
Clemens Vonrhein - Global Phasing
Patrick Pereira - SOLEIL
Daniel Eriksson - Australian Synchrotron
Abhijeet Gaur - KIT
Florin Boariu - Uni Potsdam
NIAC2026 Minutes¶
Session A: Sept 25th 08:00 UTC¶
GON (ESS):
Status
JSON on top of NeXus;
only base classes;
users not understand the sandard details;
JSON walk & SCIPP: NXtransformation viewer;
most used: NXevent_data, NXdata, NXlog, NXtextlog
plan:
NeXus in the center;
easy XML definition extensions;
smoother acquistion/writer,
better visualisation,
more NX contribution,
integration with McStas;
improvments for geometries
JK (DESY):
h5cpp, pninexus, pythin-pninexus writer
NeXpy viewer
AppDefs started to be used (NXmpes)
Need:
not all required fields are available, but it is now better because requirements are more relaxed
hdf5 performance issue with simultanious write and read
EL (HZB):
bluesky - NeXus (to NOMAD)
device definitions to NeXus
needs
mapping to App defs (pydentic model from NXDL)
referencing external asset documents
Tile integration
NXcollection -> NXbag?
MA (SESAME):
no NeXus yet, but hdf5 writer is accepting template which could be NeXus
aim: uniform data format (e.g. NeXus: NXxas, NXmonopd, NXtomo,…)
bottleneck: efficient support from NIAC can
Session B: Sept 25th 11:30 UTC¶
EMcP (SLAC):
data compression in NXmx (compression level and read is good, but not ideal)
question: any better and standardised way?
saprse data: could HDF5 lib cover it? what about looking at it as event data? or as data processing/reduction result?
LP (FAIRmat):
NeXus in NOMAD
NeXus Ontology to place NeXus Metadata into semantic ontology world
plan: more flexible experiment description, incl. multi-model experiments
need:
improve and clarify NXDL to describe semantics better
use of PIDs
link NeXus to external knowledge (e.g. ontologies)
multimodel experiments
how wide NeXus coverage shall be in terms of experiment techniques
IL (FRM II):
zoo of data formats
plan:
move to NeXus (and use it with Mantid, Miezepy, OpenHKL, Steca, Ufit, BerSANS…)
use NXtransofmration for complex geometry detector description
store simulation data in NeXus, too
also processed/reduced data should go to NeXus (like NX in Mantid)
questions:
how to best create new application definitinos
shall we propose new defintion or rather (miss)use not 100% fitting base classes
where to put unnecessary Nicos (DAQ) parameters? may be difficult to decide what is needed what is not.
shall we use master-file and original raw data to separate files
multi-modal experiments
how to use PIDs
new definitinos shall have only proper description , or name must also be descriptive?
needs of the TAS (Triple Axis Spectroscopy) community? will name harmonisation needed?
next to new AppDefs, new base classes are also needed
PB (HZB):
SECoP (Sample Environment) -> NeXus, and now more generic needs for Operando (measured during operation) experiments
needs:
multi-modal experiments
hardware setup description
link to external knowledge
supporting ‘identifier’s for fields, too, not only for groups
questions/comments:
measurements may go parallel or subsequential or overalpping
shall we have an NXmass_spectrometry or just describe things in NXenvironment? or somewhere else in the NeXus tree?
global timestamps for all subexperiments
global view (during the full experiment) for sensors/stages (not only in a subtechnique)
instead of AppDefs, maybe base classes with runtime annotation with ontology links
how to link a definition (and not a data item) to an ontology concept?
what about chemical formula which also changes during operando
discussion:
what is a blocker with NeXus
availability of tools
how to use NeXus at all?
what to do when an application (architecture/structure) misses information
archiver format? interchange format?
sematic definition being independent from actual binary representation?
how to deal with only partial data?
how to extend the schema?
NXDL is a blocker; NYAML helps, but still uncomfortable unconvential rules e.g. PARTIAL names
generic concepts are not enough to know what is the role of a specific NXslit. use specific readable name? is it enough? external link to a specification or ontology concept? documentation in datafile? feature?…)
what is the role of NIAC:
stear the definitions
also tutorials and facilitaion (better documentation) of working with NeXus?
Session C: Sept 25th 14:00 UTC¶
HO (HZB):
NeXus Creator with NXDL guided placement of (meta)data
questions/proposals:
NXDL could have better descripotions/hints for what a specific definition is for. Maybe aliases (generic choice for the name)?
what is the preferred way to create a file? Master file with slaves or a big file with mutiple entry or one big entry?
How to put description to a NeXus file (to document a specific element)?
No AppDef yet for operando_eis
YM (RWTH):
NX Appdef for TOF powder diffraction (POWTEX instrument for multidimensional measurements) following the structure of NXsnsevent
plan:
Mantid data analysis input and output results shold also go back to the NeXus file
instrument parameters should be in NeXus
problem/question:
NeXus validation issues when creating a file manually (or with NXcreator)
cnxvalidate does not recognise partial names
NeXpy also shows error regarding the incorrect use of symbols
use of curved detectors?
MY (MaxIV):
NXazint[12]d (result of azimuthal integration type of data processing): detectors -> NeXus
plan:
NeXus for MPES techniques
questions:
what is the minimal necessary data in a NeXus file? Maybe: all what is needed by data analysis tools intended to be used by the community. Consult with local and external developpers!
multiple subentries in a single entry. Shall an AppDef ask for Subentries with specific Application Defintion?
MR (ESRF):
AppDef family for XAS to cover all kinds of XAS based experiments with light processing
ESRF DAQ produced h5 files can be processed to NXxas… files after data processing
AI can interpret perfectly these NeXus files
IXAS and XAS committee of IUCr are positive
problems with NXxas NXxasproc:
not used by the community
rigid structure not supporting the actual experiment types
why two separate AppDefs? this could fit in one file
questions/suggestions:
raw data could go to NXcollection
NXprocess fields could reference data in NXcollection
What to do with data in ESRF DAQ produced hdf5 files
how to manage multi detection experiments
how deprication works?
how reference is modelled?
what about sample preparation? generic sample vs. actual sample?
discussion:
suggestion for new definitions
make prototypes (current status and additions)
try in the community
form a proposal
socialize it to NIAC
issue
PR
Telco
email lists
Ratification
Change -> NIAC vote
new contributions go to contributed definiotions, when ready -> NIAC vote
New format: well accepted
potential new communication channels: discord, slac, matrix, zulib
examples and tutorials
mock data vs. real data
correct data should be available and maintained by the community
AI knows about NeXus and can also efficiently asked
Saturday Participants:¶
NIAC in person: AB, SB, FdA, HG, WdN, ZM, MW, RB, PC, RO, (TM)
NIAC online: HB, BW, GT
other participants: IL, JK, LP, SP, RM, GON
Session D: Sept 26th 08:00 UTC¶
Agenda points
NIAC2026 Project board https://github.com/orgs/nexusformat/projects/6/views/1
Ready for vote
Ready for final check
Ready
Litle to do
Medium to do
Major to do
Further wishes to be discussed
WdN: NXxas
HG: Operando related questions
RB: example repo and its visibility
FdA: community wishes, communication
MW: tutorials, documentaion
LP: target attribute, ontology
ZM: cleaning the documentation, NXazint
AB: Has the NIAC the right size? Are we agile enough?
at the moment:
20 voting members at the moment
2/3 requirement: 13 votes
some inactive members
BW: more contributing members would be better, but inactive members are a bottleneck. Clear advertisement of the expectations. Maybe: setting up a new role those who want to be involved, but shallnot necessary hold a volting right: contributing NIAC members? (e.g. MK, LP, etc.) and have specific category for NIAC voting member.
AB: member list could also include the expertise and interests of specific contributing members.
AB: corum requirement should be reduced. 50%?
BW: rather separate the voting and non-voting members
AB: do we need a new NIAC responsibility?
now: spec, examples, validator
new: turorial?
AB: do we miss medium level tutorials?
IL: working, real facility examples with explanation why they are put together as they are
LP: how to write new definition and how to contribute to NeXus
HG: how to start with something new, like pump-probe experiments
MW: separation between Using and Developping NeXus
RB: maybe an AI prompt on top of the documentation?
WdN: move away from XML and use pydantic
AB: cleaner and simplified documentation (e.g. doctree is full with unrelevant topics)
HB: SQL ontology is needed for human tracibility
AB: let us create an issue for this
AB: make examples more visible
Examples on the main page
Examples for each App Def
More community examples (links?)
NeXus file interpretor (tool to connect NeXud groups/fields/attrs in a data file to Vocabulary Items of the NeXus definitions)
github action for checking defintions (and definitions changes) against known example data files
diataxis for examples and documentation in general
Code-Camp for it
NIAC Roles
Technical Manager
existing, but unfilled role for NAPI that is not there anymore
instead, an official validator could be added as a task for this role
RO: cnxvalidate is there but not developped any longer. Python API could be strangthened by more contributors (e.g. with pynxtools)
BW: single source of truth in NeXus is the defintion in NXDL. It shall not be the validator which provides the truth. A validator is good, but it should follow the NXDL definitions. Can a single person be responsible for guaranteeing integrity between definitions and validation? Tech manager shall be responsible for the validation tool and we also need one for managing NXDL.
HB: NeXus connectivity to databases should be enabled. Database referential integrity should be maintained via normalisation.
SB,LP: NOMAD (in FAIRmat) solves the probelm using mongoDB
HG: ontology, triplets and SPARQL is also a way (DAPHNE is looking at)
AB: we need a specific example to demonstrate the actual probelm
Ontology Manager
it can be defined as an official role
ensures the relationship with semantic world
NIAC Executive Chair
FdA is volunteering
SB secunded
noone else volunteered
accepted (13/0/0)
NIAC Executive Secretary
RB is volunteering
RO secunded
noone else volunteered
accepted (13/0/0)
NIAC Definition Release Manager
PC is volunteering
RB secunded
noone else volunteered
accepted (13/0/0)
PR #1331
BW: allowing multiple mirrors, we may want to give an attribute for the role of the mirror
PC,SB: NXcomponent already allows the description of even complex beam paths, so even more than just a role can already now be described
GT: it is not clear why NXmonochromator exists at all if NXcomponent would be just enough
AB: put the questions into an issue
accepted (11/0/2)
Session E: Sept 26th 11:30 UTC¶
PR #1327
RO: why not an NXenvironment for (every) NXcomponent
LP: yes, but specializing an NXinstrument with special description provides a possibility for a recepie how to describe its environment
WdN: Warning! NXenvironment has NXcomponents, so an NXcomponent would have NXcomponents inside.
AB: just take it as is. Note that if a subcomponent has an environemnt already defined (e.g. Sample) than that this environemnt should be used instead.
BW: an environemnt should be external to the component it is providing environment for.
SB: Can an NXinstrument has another NXinstrument inside? Similarly, an NXcomponent another NXcomponent inside?
AB: We can support the specific requests as they are coming.
BW: +1, We can now add where it is now requested and if new request comes, we can then add there, too.
HG: Operando project is addressing this question, so we may wait until the request is clarified.
SP: as BW said, we can add it to both places
GON: be carefull with its use
AB: go for it with clear description
RO,SB: specialisation of excluding the possibility to have an NXenvironemnt in /NXcomponent/NXsensor and NXactuator is not needed.
accepted (11/1/1)
PR #1330
accepted (13/0/0)
BW: documentation could be further clarified that both funtion and/or mechanism can be described here.
AB: this documentaion improvment does not need a special vote
PR #1654
SB: original aim was to warn people not to write free text, but rather reference existing documentation (e.g. ISO standard, Instrument manual, etc.) if possible. This is actually a general rule, and can be made clear as a general idea in the documentaion, rather then writing it everywhere.
accepted (12/0/1)
PR #1653
PC: Is is needed at Diamond and shall be used in NXdetector
RO: It is like a view definition. Is not this definition too specific?
PC: Indeed, if it needs to be extended, it can be done.
GON: signal and aux_signal in NXdata shall be consistant. Different downsampling requires multiple NXdata results.
What is in front of us:
AFM/SPM PR#1632
5 App Def
16 Base Classes
rendered documentation is under https://fairmat-nfdi.github.io/nexus_definitions/classes/contributed_definitions/spm-structure.html
XAS PR#1619
@target
Session F: Sept 26th 14:00 UTC¶
PR#1619 XAS (see also PR#1352)
AB: community needs NXatom and NXelement as separate concepts
SB: NXelement: why do we have long enum list with docuemtation repeating well known physics standard?
BW: NXauger_line/NXemission_line: why an enum list rather than a regexp?
WdN: auger lines do not seem to be a complete list
PC: The list in current base class does not support properly neutron spectroscopy
BW: next to element, a separate definition is needed for isotopes
AB: Would not it be enough to add mass number to NXelement?
HG: enumeration allows ontology mapping to external knowledge base.
NIAC suggestions and questions are posted to the PR
WdN: request was to keep it in contributed
AB: if community agrees, this could go to the standard base classes directly
accepted with the notes (12/0/1)
PR #1640 XAS
WdN: AppDefs are requested to stay contributed for the time being
NIAC discussed several topics and put suggestions into the PR
