Repository navigation
kdaectrl: fill out more of nexus_structure in run start #45
Description
in a run start we currently just add placeholders for blocks and for events.
we should write some static fields (based off KDAECTRL's PV values), these are the easy ones:
title - based on TITLE (assume this won't change and just do it static for now, #44 needs to be implemented for this)
start_time - based on start time of message ( we already put this in the run start)
name - the instrument name
run_number - the run number
beamline - the instrument name
program_name - probably shouldn't be ISISICP
the /instrument group
which contains
- name - the instrument name
- source (a group) containing:
- name: ISIS
- probe: neutrons
- type: Pulsed Neutron Source
potentially more challenging:
run_cycle - the current cycle. how does the ICP get this?
experiment_identifier - not sure what this is
as part of this ticket we should actually document these fields in the dev wiki.
todo: there are also some fields which can only be written at the end, write tickets for these.
Activity
[-]fill out more of nexus_structure in run start[/-][+]kdaectrl: fill out more of nexus_structure in run start[/+]Tom-Willemsen commentedon Jul 14, 2026
I feel we should defer this until after we have considered filewriter requirements in detail - it is possible we may decide not to use
nexus_structureas it currently stands.Tom-Willemsen commentedon Oct 1, 2026
The NeXus structure we currently generate from ISISICP has been documented in ISISComputingGroup/ibex_developers_manual#253
The vast majority of the datasets/structure listed there will need translating into the
nexus_structureemitted by kdaectrl.For those listed as static/metadata, this would just be as a statically defined dataset in the
nexus_structure(which kdaectrl needs to compute when it streams the run start).For those areas that need dynamic data, we need
moduledefinitions which match up with a writer-module defined inkafka_file_writer. These modules will need module-specific configuration information, for example which topics to listen to or binning parameters to use etc.I think we're now in a place that we could start on this ticket, especially with the static structure items and the overall group structure. May require some back-and-forth with filewriter implementation work.