Ticket #10463 (assigned)
LoadNexusProcessed
| Reported by: | Owen Arnold | Owned by: | Owen Arnold |
|---|---|---|---|
| Priority: | major | Milestone: | Backlog |
| Component: | Framework | Keywords: | Student |
| Cc: | Blocked By: | ||
| Blocking: | Tester: |
Description
Look in LoadNexusProcessed, and you will see several places:
histo = m_spec_min - 1;
This is not correct. The spectrum number to workspace index number is not necessarily offset by one, and hardcoding it like this is bound to cause trouble in the future. There's plenty of functional test coverage here, so you're unlikely to really break things in the process of fixing. However, do check that the solution does not degrade performance.
Change History
comment:1 Changed 6 years ago by Nick Draper
- Owner changed from Anyone to Owen Arnold
- Status changed from new to infoneeded
comment:2 Changed 6 years ago by Owen Arnold
- Status changed from infoneeded to new
Once 10385 has been merged to master (currently waiting). Look at extractMappingInfo, particularly detgroup.openNXInt("spectra") because this is where the information comes from.
One way around this problem would be to try to perform readInstrumentGroup, which calls the methods above, as early as possible in the processing, as this gets the correct information, and would avoid you having to make the same call twice.
My suggestion would be to deliberately write a file where the spectrum numbers are not offset by 1 to the workspace index. This would be a good regression test case. This could be achieved by running crop workspace, and saving the result, which could then be loaded via LoadNexusProcessed.
On a related note, many of the load algorithms are in a really bad state! They are extremely hard to read, contain lots of duplicated code. I fear that this is going to come back and bite us!
Owen can you elaborate a bit on the correct way to get the mapping in this case.