Ticket #3390 (assigned)
ConvertUnits should mask detectors that have no neutronic positions
Reported by: | Stuart Campbell | Owned by: | Stuart Campbell |
---|---|---|---|
Priority: | major | Milestone: | Backlog |
Component: | Framework | Keywords: | |
Cc: | taylorrj@… | Blocked By: | |
Blocking: | Tester: |
Description
For the detectors that do not have the necessary information to perform a unit conversion (i.e. those with no neutronic positions) we should mask them.
Change History
comment:3 Changed 9 years ago by Stuart Campbell
- Cc taylorrj@… added
Russell: Is this the correct way to do it ?
comment:4 Changed 9 years ago by Russell Taylor
No, I don't think that's going to be doing the right thing. First of all, the maskWorkspaceIndex method is on MatrixWorkspace so there's no need for the 'if (events)' test. It also takes care of zeroing out the data.
HOWEVER, it has at the top of the method there's code that looks for a detector and returns immediately if it doesn't find one (which is going to happen every time in this case). I need to look into where that code came from and whether it should be there (I'm thinking not).
comment:5 Changed 9 years ago by Russell Taylor
Actually, thinking some more I'm not sure what happens in this case. Typically, you get to the point where the masking call is if there's not detector pointed to by a particular spectrum. Presumably here there is a related detector, but it doesn't have a meaningful position (L2=0, 2theta=?). I'd need to see an example to know exactly what happens in this situation.
comment:6 Changed 9 years ago by Stuart Campbell
- Status changed from accepted to assigned
- Owner changed from Stuart Campbell to Anyone
comment:7 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 30 to Iteration 31
Bulk move of tickets to iteration 31 at the iteration 30 code freeze
comment:8 Changed 9 years ago by Nick Draper
- Milestone changed from Iteration 32 to Iteration 33
Moved to iteration 33 at iteration 32 code freeze
comment:9 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.1 to Release 2.2
Moved at end of release 2.1
comment:10 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.2 to Release 2.3
Moved at the end of release 2.2
comment:11 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.3 to Release 2.4
Moved to milestone 2.4
comment:12 Changed 8 years ago by Nick Draper
- Milestone changed from Release 2.4 to Release 2.5
Moved at the code freeze for release 2.4
comment:13 Changed 7 years ago by Nick Draper
- Milestone changed from Release 2.5 to Release 2.6
comment:14 Changed 7 years ago by Nick Draper
- Owner changed from Anyone to Russell Taylor
Russell, could you take a look at this when you are back and add a note on the current situation and recommendation?
comment:15 Changed 7 years ago by Russell Taylor
A few notes after a little research:
- Stuart's original commit from comment:2 is [c5bc4b35]
- I made a small refactoring commit [61d7db76] which didn't make it into trac. The code is unchanged since then.
- I rectified the problem mentioned in the second part of comment:4 in [8669a1ab]. That was the last change to this method.
Next step is to reconsider what I said in comment:5.
comment:16 Changed 7 years ago by Russell Taylor
What happens for spectra related to detectors that have no neutronic position is that the data is zeroed out, but no masking flag is added as no corresponding detector object exists in the 'neutronic' instrument. You could in principle add code to fetch the detector with that ID in the 'physical' instrument and add a masked flag to that. I think the only effect of this would be to grey them out when viewing the physical instrument.
comment:17 Changed 7 years ago by Russell Taylor
An additional question was what happens if an efixed value is missing from a particular detector where it is otherwise specified per-detector in the IDF (see e.g. BASIS). What happens is that the efixed value is taken to be EMPTY_DBL for that pixel. All bin boundaries end up at approx -EMPTY_DBL. For an event workspace, the 'tof' values in the event list would also be at -EMPTY_DBL and disappear from the histogram representation. For a Workspace2D, the counts in a particular bin are unaffected.
I expect this all happens by accident rather than by design, and is probably not what you want to happen if there is indeed a use-case for not specifying the efixed on some pixels.
N.B. This is the case irrespective of whether a both neutronic & physical positions have been defined.
comment:20 Changed 7 years ago by Nick Draper
- Milestone changed from Release 2.6 to Backlog
Moved to backlog at the code freeze for R2.6
comment:21 Changed 7 years ago by Nick Draper
- Status changed from new to assigned
Bulk move to assigned at the introduction of the triage step
comment:22 Changed 6 years ago by Russell Taylor
- Owner changed from Russell Taylor to Stuart Campbell
Stuart, handing this back to you to decide what to do with it (if anything).
comment:23 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 4237