Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add polarisation spin state to ISIS ORSO file metadata #36685

Open
rbauststfc opened this issue Jan 23, 2024 · 0 comments
Open

Add polarisation spin state to ISIS ORSO file metadata #36685

rbauststfc opened this issue Jan 23, 2024 · 0 comments
Assignees
Labels
ISIS Team: LSS Issue and pull requests managed by the LSS subteam at ISIS Reflectometry Issues and pull requests related to reflectometry
Milestone

Comments

@rbauststfc
Copy link
Contributor

rbauststfc commented Jan 23, 2024

For POLREF data, we need to identify which spin state is being saved by populating the measurement->instrument_settings->polarization metadata in the header of the ISIS ORSO file that's produced by SaveISISReflectometryORSO. For example, in the .ort ASCII file you would see:

#   measurement:
#     instrument_settings:
#       polarization: po

We should also include the spin state in the dataset name. Currently, for data from workspace groups we're including the workspace name and incident angle in the dataset name to avoid generating duplicates, i.e. # data_set: ws_grp_name_1 0.5.

This should be changed so that workspace groups for polarised data use the incident angle and spin state (instead of the workspace name) to uniquely identify each dataset. This would appear as follows in the file:

# data_set: 0.5 po

We should use the following notation in the ORSO file to identify the spin state:

  • PNR (half-polarised): po or mo
  • PA: pp, pm, mp or mm

Eventually there would be an ANR (with only the analyser) case, however we don't currently support ANR reduction in Mantid, so this is out of scope of this issue.

To identify the spin state of a workspace in the SaveISISReflectometryORSO algorithm, I think the most reliable approach would be for polarisation correction algorithms PolarizationCorrectionWildes and PolarizationCorrectionFredrikze to add an entry to the sample log that provides this information for each child workspace in the input group.

Our scientists have expressed a preference that we use the ORSO notation in our sample log. The two correction algorithms use different notation for parallel and anti-parallel:

  • PolarizationCorrectionWildes: we should set the spin state in the sample log from the name of the output workspace. For example, the Wildes ++ output workspace would be spin state pp, +- would be pm, -+ would be mp and -- would be mm. It's important to set the spin state based on the output workspace name rather than the input flipper configuration as the Wildes flipper configuration does not tell us the spin state, it just tells us which flippers are on or off on the instrument. An instrument can be set up for cross-polarization, which would mean the flipper configurations correspond to different input spin states than they would normally. Regardless of the instrument setup, the maths in the calculation handles this automatically so that the final outputs are labelled with their correct spin state.
  • PolarizationCorrectionFredrikze: subscripts pp, pa, ap, aa are used for the input measurements and corrected outputs. The p represents parallel and a represents anti-parallel, so here we are passing in the spin states directly and no further information is needed about the instrument setup. Therefore, we should again set the spin state in the sample log from the name of the output workspaces as follows:
    • PA: output pp workspace will be spin state pp, output pa is spin state pm, output ap is spin state mp, output aa is spin state mm.
    • PNR: output p workspace will be spin state po, output a is spin state mo.

I have opened the following issues to handle adding the spin state to the output workspaces produced by the correction algorithms:

@rbauststfc rbauststfc added Reflectometry Issues and pull requests related to reflectometry ISIS Team: LSS Issue and pull requests managed by the LSS subteam at ISIS labels Jan 23, 2024
@rbauststfc rbauststfc added this to the Release 6.10 milestone Feb 21, 2024
@rbauststfc rbauststfc modified the milestones: Release 6.10, Release 6.11 Apr 12, 2024
@rbauststfc rbauststfc added the Awaiting User Response Waiting on input or testing from a third party label Jun 14, 2024
@rbauststfc rbauststfc removed the Awaiting User Response Waiting on input or testing from a third party label Jul 3, 2024
@rbauststfc rbauststfc modified the milestones: Release 6.11, Release 6.12 Sep 13, 2024
@rbauststfc rbauststfc self-assigned this Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ISIS Team: LSS Issue and pull requests managed by the LSS subteam at ISIS Reflectometry Issues and pull requests related to reflectometry
Projects
Status: Icebox
Development

No branches or pull requests

1 participant