ess.dream: mantle DETECTOR_BANK_SIZES has counter and strip swapped
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 88/100
Research direction
Start in ess.dream.workflows and inspect DETECTOR_BANK_SIZES, comparing its dimension order with the DREAM detector ICD and the geometry file named in the issue. Swap the final counter and strip entries, then verify that folded detector ids preserve neighbouring strips along z and the counter relationship described in the issue.
Written by the indexing model from the issue text.
Description
DETECTOR_BANK_SIZES in ess.dream.workflows folds the mantle as
{"wire": 32, "module": 5, "segment": 6, "strip": 256, "counter": 2}
but the DREAM detector ICD (ESS-5462547, section 4.4.3) defines pixel = 256·(60·wire + 12·MU + 2·cassette + counter) + strip + 1, i.e. C-order (wire, module, segment, counter, strip). The geometry file (geometry-dream-no-shape-2026-06-09.nxs) agrees with the ICD: consecutive ids are neighbouring strips along z, and id + 256 is the other counter.
With the current order, folded strip jumps from z = +1078 mm back to -1091 mm at index 128, and counter is strip parity (adjacent strips 13 mm apart in z, same azimuth). Positions are folded with the same order, so anything that only uses coordinates is unaffected; anything selecting or labelling by strip/counter is not.
Fix: swap the last two entries.
Found while fixing the live-data logical views in scipp/esslivedata (they no longer use this dict).
- Dominant language
- Python
- Stars
- 2
- Forks
- 5
- Avg merge
- 4d 16h
- Merged PRs (30d)
- 21
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from scipp/ess
-
[essnmx] essmandi-reduce writes entry/instrument/name = "NMX" for MANDI dataPossibly taken @YooSunYoung claimed this 24 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
[essnmx] Fix typo in NXLauetof application definitionMay be free again @nightcityblade claimed this 17 days ago, and no pull request is open. Openessnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
essdiffraction
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
[essimaging] `maximum_resolution_achievable` should not hardcode "time" as the "third" dimensionPossibly taken @jokasimr claimed this 180 days ago. Openessimaging
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
essreduce
Difficulty 1/5 Under an hour Newbie friendliness 72/100
Maintainers usually reply within 1 day
Similar issues
-
area:space-accuracy good first issue track:data
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Sara-Managed-Projects/space-radar#904 ·
Maintainers usually reply within 1 day