search

mantidproject / mantid

Main repository for Mantid code
https://www.mantidproject.org
GNU General Public License v3.0
211 stars 124 forks source link

Calibration step for POLREF reductions #34934

Open rbauststfc opened 1 year ago

rbauststfc commented 1 year ago

A calibration step is required to support reductions for POLREF. Requirements still need to be clarified, but we're looking at if/how we could extend the new ReflectometryISISCalibration algorithm to support this. This is likely to involve taking some logic from the RotateDetectorIntoPlace function that is defined within QSumFunctions.py of POLREF's reduction code. The key things that need to be supported that we don't have in our calibration algorithm at the moment seem to be:

  1. The calibration measurements they take are relative theta values (that are used to find the absolute positions to move the pixels to), rather than absolute mm positions, which is what the algorithm currently expects. An example of the calibration data they measure (in NeXus format currently) can be seen in Andrews repo at Calibrations -> Cycle_18_13 -> OSMOND_Map_18_3_thetaScan_thVsCl_pixelsRemoved.nxs.
  2. In our existing algorithm we find the specular pixel from the IDF, however POLREF need to be able to specify their specular pixel and also a value for theta, as these change frequently (due to changes in the rotation of their sample table, I believe).
  3. We would need to add a step to calculate the Cartesian co-ordinates from the polar co-ordinates. There is some code for doing this in the RotateDetectorIntoPlace function in Andrew's code (see lines 263-264).
  4. POLREF need to move both the horizontal and vertical co-ordinates of their pixel locations, while our algorithm currently only moves the vertical location. Additionally, the POLREF IDF defines the vertical co-ordinate as z, while our algorithm has hard-coded moving y (which matches the defined vertical co-ordinate for INTER). We need to think about handling this. Changing the IDF for POLREF would have significant knock-on consequences for their reduction scripts, so should be avoided if possible.
github-actions[bot] commented 11 months ago

This issue has been automatically marked as stale because it has not had activity in 6 months. It will be closed in 7 days if no further activity occurs. Allowing issues to close as stale helps us filter out issues which can wait for future development time. All issues closed by stale bot act like normal issues; they can be searched for, commented on or reopened at any point. If you'd like a closed stale issue to be considered, feel free to either re-open the issue directly or contact a developer. To extend the lifetime of an issue please comment below, it helps us see that this is still affecting you and you want it fixed in the near-future. Extending the lifetime of an issue may cause the development team to prioritise it over other issues, which may be closed as stale instead.

github-actions[bot] commented 10 months ago

This issue has been closed automatically. If this still affects you please re-open this issue with a comment or contact us so we can look into resolving it.