adjustments and redactions

## Attendees (reconstructed from notes)

In the hack-a-thon room: John Hetrick, Valeria Lauter, Tim Charlton,

In the hack-a-thon room: John Hetrick (Remote), Valeria Lauter, Tim Charlton, Erik Watkins,

Marie Backman, Glass Elsarboukh, Kevin Tactac, Asmaa Qdemat (named on

p.11). Addi Malviya-Thakur attended ad-hoc portions (p.7 summary:

"Addi — to ask/assign weights"). Bogdan chaired. Erik Watkins and

Becky Anderson are not explicitly named in the Day-3 notes — they

may have dialled in or attended intermittently.

"Addi — to ask/assign weights"). Bogdan chaired.

Becky Anderson was on travel.

In the optional Mantid Replacement meeting (side-room 8600 AG-06):

Peli (chair?), Jon, Matt, Malcolm, Joe, Yingrui, Yongping, Michael,

Chris, Zach, Andre, Jean. (This was a cross-facility STS / FTS /

HFIR-scope conversation.)

Pete Peterson (Chair), Jon Taylor, Mat Doucet, Malcolm Guthrie, Joe Paddison, Yingrui Shang, Yongpeng Zhang, Michael Walsh,

Chris Fancher, Zach Morgan, Andre Savici, Jean-Christophe Bilheux, Volker Urban (remote), David Dahlbom, Reece Boston, Doug Abernathy,

Yongquing Zhang, Luc Dessieux (remote?), John Hettrick (remote), Alan Hicks (remote?), Marie Backman, Matt Tucker, Mark Lumsden, Kyle Ma (remote?), Xiao Hu (remote?), Addi Malviya Thakur (remote).

(This was a cross-facility STS / FTS / HFIR-scope conversation.)

---

- **Tim:** Gaussian / Poisson statistics (Gauss-y vs. count-y) matter

  for which default is physically right.

- **Re D2 — the "monster configuration class."** Marie wants to

  refactor. Dossier item: *Break up this God class; split into

  refactor. Dossier item: *Break up this god class; split into

  `GlobalReductionConfiguration`, `RunConfiguration`, and

  `PlotConfiguration`.*

The labeled working question on the whiteboard: *"what we do 1st so

that things happen sooner."*

- Bogdan framed the three-legged order: **(modularity, add LR, which

- Bogdan framed the three-legged order: **(modularity, add LR, then unify

  BE).**

- **Tim:** choose order wisely — *"gets us to finish sooner."*

- **Valeria:** *"getting results is most important!"* (working

### Monorepo discussion (p.16)

- **Glass:** **monorepo initiative** — front-end (all JavaScript) UI

- **Glass:** **Monarch Initiative** — front-end (all JavaScript) UI

  and API; back-end env; middle (API dir) for database-access

  concerns. Wants a monorepo model.

- Caveat: somewhat more complicated to host both. E.g. reflectometry

  `mr_reduction` holds reduction-list for QuickNXS.

- **Marie:** good discussion for Monday (the deep-dive day). E.g.

  Hyspecpt is much smaller and doesn't have a BE — not a template for

  Hyspecppt is much smaller and doesn't have a BE — not a template for

  us.

### Time-and-effort reality check (p.16–17, Part-2 transcript

  approaching them is *"out of luck"*; an ORSO labelling fix landed

  in ~20 minutes once the right individual was contacted. Take-away:

  process overhead dominates arithmetic estimates.

- **Marie:** SANSView development is another example in the same vein.

- **Marie:** SASView development is another example in the same vein.

### Recap at end of session (p.16 mid)

## 15:00 – 16:00 · Optional — "Mantid future" discussion (side room)

A parallel, cross-facility meeting in 8600 AG-06, attended by a

different group (Peli/Jon/Matt/Malcolm/Joe/Yingrui/Yongping/

different group (Pete/Jon/Matt/Malcolm/Joe/Yingrui/Yuanpeng/

Michael/Chris/Zach/Andre/Jean). Notes are in a separate PDF

(`20260424175425.pdf`). Summarised here for completeness — this is

*not* a hack-a-thon decision; it informs the *technology-substrate*

- **Matt:** Gen-2 detector requires each channel redefined; not

  straightforward; fine pixelation.

- **Yongping:** redefine IDF; X/Y conventions not clear today; took a

- **Yuanpeng:** redefine IDF; X/Y conventions not clear today; took a

  long time. **Must clearly handle geometry.**

- **Malcolm:** totally agree. Virtual pixel but not static (detectors

  move). **Dynamic redefinition of virtual pixels would be insanely

  useful.**

- Q: on DAQ or in Reductor? — A: Reductor, because Reductor doesn't

- Q: on DAQ or in Reduction? — A: Reduction, because Reduction doesn't

  know what samples are acquired at native pixels.

- **Matt (wire-chamber example):** some detectors have no native

- **Mat/Bogdan (wire-chamber example):** some detectors have no native

  pixel number; to reconstruct position you need a pos-cal in the

  Reductor. Venus-style TuePres/TuePic_4 clustering → *"position

  calibration in Reductor."* Or stream somewhere upstream.

  Reductor. Venus-style TimePix3/4 clustering → *"position

  calibration in Reduction."* Or stream somewhere upstream.

### Adaptive meshes & sparse matrices (p.3)

- Should we generalise anything except the final column-ASCII?

- **Joe:** *"everyone should be fully reduced. The best service a

  reduction [code] provides is: reduction is correct!"*

- **Matt:** store file in format as described; **retrieve it in the

- **Mat:** store file in format as described; **retrieve it in the

  format you ask for** (parquet, tiled, ASCII, ORSO, …). Tiled-model

  marked as *"good idea"*.

- **Joe:** data reduction is basic infrastructure — users don't want

  because none of the first 30 are suitable. User wants a button that

  says "absorption-correction." For any instrument, a basic reduction

  procedure can be made the same — **a Universal Reductor Interface.**

- **Peli:** likes this.

- **Pete:** likes this.

- **Jon:** Mantid's problem is a 2000s-body-of-thinking — it holds

  data, is not an instrument group, concept of algorithm is primary.

  Today everything is in a DB; the abstraction has become a source of

  uncertainty about what the code is doing.

  uncertainty about what the code is doing. This is *"important"*.

### "How do we know the reductor is correct?" (p.6)

### "How do we know the reduction is correct?" (p.6)

- **Jon:** rewrite the reductor in another tool; don't do it

- **Jon:** rewrite the reduction in another tool; don't do it

  differently at each instrument.

- **Peli:** define a standard long-soaked-std file.

- **Pete:** define a standard long-soaked-std file.

- **Michael:** reason we have 30 diff-above-correct Mantid algorithms

  is that 30 different groups each want one and 10 years pass — do we

  support people who will do this?

- **Jon:** current framework (Mantid) — *algorithm became currency*,

  not "understanding of what it takes to perform."

- **Malcolm:** shaves on algorithms.

- **Malcolm:** shares algorithms...

- **Jon:** trick is not trying to find A → B efficient; treat it [as

  Mantid failed originally] — someone decided all-set-in-stone for

  ~26 years.

- **Carefully think about:** how data comes out; what you do to it;

  extract science from it.

- **Matt:** separate out instrument-specific bits; that is the way.

- **Preg:** do what you need to get data out of instrument.

- **Mat:** separate out instrument-specific bits; that is the way.

- **???:** do what you need to get data out of instrument.

### Candidate substrates (p.8–10)

- **Peli:** SCIPP — Math, Convert, Load data ← `.nxs`.

- **Pete:** SCIPP — Math, Convert, Load data ← `.nxs`.

- **Jon:** best way to do data processing (STS C1543 worked example):

  talk data, trim models.

- Substrate ideas to come up with: **Databroker? Bluesky?**

- Quote Martin: *"Talk about the problem, not the solution."*

- **Yongping:** take corrections into account — determines the

- Substrate ideas to come up with: **Database? Bluesky?**

- To Quote ??? Martin: *"Talk about the problem, not the solution."*

- **Yuanpeng:** take corrections into account — determines the

  architecture (e.g. normalization). Profile performance

  comprehensively.

- **Peli:** many instruments work on a stream of events.

- **Pete:** many instruments work on a stream of events.

- **Yingrui:** data-structure discussion.

- **Peli:** *not a dev decision today.* Pulling a data-structure is

- **Pete:** *not a dev decision today.* Pulling a data-structure is

  "imagining"; **Python is expected as the API.**

- Language speculation (p.10): *"Rust?"* — *"we're not so awesome at

  Rust (at C++, seems); we're pretty awesome at Python."*

  Rust (or C++, seems); we're pretty awesome at Python."*

This meeting did not close on a decision. Bogdan captured the room's

scope for the next session: **visualization + performance**, and a

  result-cache semantics. Bogdan asked the room to push this to Day

  4 / Monday.

- The **`.nxs` vs `.nxs.h5`** load-path decision (`h5py` pre-inspect

  vs. `LoadNxs`) — both on the board.

  then `LoadEventNexus()` vs. `Load()`) — both on the board.

- **Valeria's perpendicular question** — the "multi-reflectivity

  extract" UX (multiple reflectivities from one define-scale

  operation, multiply ROI for the same peak) — where the

  back-end substrate question, but it is **not a hack-a-thon

  decision**. If any of those bullets need to feed into the

  hack-a-thon plan, Bogdan will call them out explicitly.

- Asmaa Qdemat is named once on p.11 ("Asmaa: asked something");

  Becky and Erik do not appear by name in the handwritten Day-3 notes

  at all. If they were present, the notes captured them as part of

  the room rather than by attribution. Please correct in review.

---