Ticket #8369 (closed: duplicate)
Investigate IntegratePeaksMD issue reported by Pascal
Reported by: | Owen Arnold | Owned by: | Martyn Gigg |
---|---|---|---|
Priority: | critical | Milestone: | Release 3.3 |
Component: | Diffraction | Keywords: | |
Cc: | lynchve@… | Blocked By: | |
Blocking: | Tester: | Owen Arnold |
Description
Attachments
Change History
comment:2 Changed 7 years ago by Owen Arnold
I've tracked this down to the changes made in #4998. The basic procedure for determining whether an integration region is valid is to:
- Generate 64 test points on the sphere using the integration radius or the integration background radius.
- Convert those points into fictional peaks themselves.
- Using the QLab coordinates of those peaks, determine the Kf vector for each. Then using the sample location, use ray tracing to determine what detector would be hit. Use that as the detector for each peak. If no detector is found, then the sphere must sit over the edge of the detectors, so give-up the rest of the fictional peak processing and show a warning.
However, this isn't working for WISH. It seems that the detector locations found are much further away from the origin of the peak than one would expect. I'll attach a script to demonstrate this problem.
comment:4 Changed 7 years ago by Owen Arnold
Further to above, I wonder if this is a scenario where multiple detectors may contribute to the same QLab region, because the algorithms workings seem sound to me.
comment:5 Changed 7 years ago by Owen Arnold
- Status changed from new to verify
- Resolution set to fixed
- Milestone changed from Release 3.1 to Release 3.2
This does still need to be done, but it can wait till 3.2.
comment:6 Changed 7 years ago by Owen Arnold
- Status changed from verify to reopened
- Resolution fixed deleted
Accidentally tried to close this.
comment:7 Changed 6 years ago by Owen Arnold
- Priority changed from blocker to critical
- Milestone changed from Release 3.2 to Release 3.3
There are now 4 algorithms that can be used for SC peak integration.
IntegratePeaksMD IntegrateEllipsoids IntegratePeaksUsingClusters (new for 3.2) IntegratePeaksHybrid (new to 3.2)
The latter two work on WISH and can be used for non-spherical peaks.
The original issue still remains, (the report of the false positive), but this is now a critical issue rather than a Mantid blocker. I'm moving it to 3.3.
comment:8 Changed 6 years ago by Owen Arnold
- Milestone changed from Release 3.3 to Release 3.2
We should at least have an answer as to why this is happening, as Pascal has repeatedly asked about it. This is almost definitely an issue of false positives in the warning reports.
comment:10 Changed 6 years ago by Nick Draper
- Owner changed from Anyone to Martyn Gigg
Martyn,
Could you talk to Owen and take a look into this?
comment:11 Changed 6 years ago by Andrei Savici
IntegratePeaksUsingClusters and IntegratePeaksHybrid are using a different method to check if detectors are on the edge. I found a strange omission in the old method. In IntegratePeaksMD2, the test peaks are constructed on detectors at 1 meter away from the sample. It is not the one causing problems in the test, but it should be fixed. Also, to comment on comment 4, There cannot be 2 detectors contributing to Qlab (but they could for the same Qsample, if appropriate goniometer/wavelengths are used)
comment:12 Changed 6 years ago by Martyn Gigg
- Milestone changed from Release 3.2 to Release 3.3
It looks like the issue for WISH is that the IDF is defined such that there are very small gaps between the tubes. This means that occasionally a point on the integration sphere is generated such that it's traced position falls down one of the gaps and doesn't register a hit and the algorithm then assumes that this means it has fallen of the edge of a detector (which technically it has). It's just that in this case we want the detector to mean the whole bank and not a tube.
comment:13 Changed 6 years ago by Martyn Gigg
- Status changed from reopened to inprogress
Fix indentation error in usage example.
Refs #8369
Changeset: b27c77cdc27790183cb8acf600560d9086b0030b
comment:14 Changed 6 years ago by Martyn Gigg
Relax contraint for determing in a given Q is on a detector
It now only requires 75% of points tried to hit something, which will allow for small gaps between pixels/tubes in banks not to affect the overall test of whether a pixel found. Refs #8369
Changeset: d8842edc94a80daa2709cdc0ad87c911bb46e889
comment:15 Changed 6 years ago by Martyn Gigg
Minor refactoring of method signatures to avoid copies.
Refs #8369
Changeset: c66397b960af075f7428fc930982b25c1c704f7e
comment:16 Changed 6 years ago by Martyn Gigg
Reorganise headers into alphabetical order
Also removes unrequired headers. Refs #8369
Changeset: d64eec6ba4bfae6a5a0384e9454cf24b938e70ea
comment:17 Changed 6 years ago by Martyn Gigg
- Status changed from inprogress to verify
- Resolution set to duplicate
comment:18 Changed 6 years ago by Owen Arnold
- Status changed from verify to verifying
- Tester set to Owen Arnold
Agree
comment:19 Changed 6 years ago by Owen Arnold
Agreed. Pascal has suggested solving this problem by repeating the ray tracing around around a circle to determine if there are neighbouring tubes, or if this is really an edge. Read - a ray with thickness.
comment:21 Changed 6 years ago by Owen Arnold
NOTHING MERGED.
comment:22 Changed 5 years ago by Stuart Campbell
This ticket has been transferred to github issue 9214
2 Days