-
Notifications
You must be signed in to change notification settings - Fork 121
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 absorbtion corrections to the OSIRIS scripts #35430
Conversation
@MohamedAlmaki Thers's no need for the option of Simple or PP. PP will do both. |
@SpencerHowells I added this option because other diffraction instruments have similar options in their scripts, and we wanted to create a standardized interface across all diffraction instruments. Does this option irrelevant to OSIRIS specifically and other instruments can benefit from it? |
9ec59e5
to
3002a73
Compare
I have removed myself as I am going to be on holiday and dont want to block this getting reviewed |
:param run_details: the run details of the workspace. Unused parameter added for API compatibility. | ||
:return: A workspace containing the corrections. | ||
""" | ||
events_per_point = 1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be hard coded or an argument with a default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be a parameter. I will add it as a parameter
Could you please add some tests for checking the new functionality. |
"Test_PaalmanPings_Absorb", | ||
"OSI120032_d_spacing.nxs", | ||
absorb_corrections=True, | ||
empty_can_subtraction_method="PaalmanPings", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we also have a test for the simple option too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is already added here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a reason they are not two tests in the same class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think from a separation of concerns perspective, it is better to implement every test in its own class. Also, it will be clearer to see every test separately in the test output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
most tests in Manitd use one class with different options. Having a class for each one makes the file very long (repeated boiler plate) and makes it easy to miss things (e.g. me not spotting that you had the test)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, there is a lot of duplicate code. From my understanding, I guess using one class is the case in C++ but in Python, it is not. Because the test interface is designed to run one test you need to implement runTest
and validate
. So it will be strange to run two tests in runTest
function. To reduce code duplication I can write a common test class for all the tests as in Pearl Tests. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, its a system test and not a unit test. Sorry I missed that, hence my comments.
A template class would help. I think thats a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, ok, I will do that
The tests look much cleaner now. Thank you. Once the builds pass I will approve it |
I didn't notice that there is a mismatch problem in one of the tests. I will fix it |
👋 Hi, @MohamedAlmaki, Conflicts have been detected against the base branch. Please rebase your branch against the base branch. |
d5c63ca
to
2ce8ffc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like it works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of comments, I think it would be good to change one of the parameter names for consistency, but as for the ReplaceSpecialValues
threshold, I think we can defer this to a separate PR
@@ -25,5 +26,15 @@ | |||
ParamMapEntry(ext_name="xye_filename", int_name="xye_filename"), | |||
ParamMapEntry(ext_name="sample_empty_scale", int_name="sample_empty_scale", optional=True), | |||
ParamMapEntry(ext_name="keep_raw_workspace", int_name="keep_raw_workspace", optional=True), | |||
ParamMapEntry(ext_name="absorb_corrections", int_name="absorb_corrections"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be named in a way that is consistent with the other instruments e.g.
ParamMapEntry(ext_name="do_absorb_corrections", int_name="do_absorb_corrections"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to do this but I noticed the previous parameters don't follow the convention of the other instruments (e.g. vanadium_normalization not do_vanadium_normalization). If I changed all of the parameters the users using the existing script will have to change it. In addition, the OSIRIS users probably don't use other instrument scripts so they will not notice this inconsistency. What do you think?
:param run_details: The run details of the run number | ||
:return: the vanadium path | ||
""" | ||
|
||
return run_details.unsplined_vanadium_file_path | ||
|
||
def get_vanadium_normalization_cutoff(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally instrument settings are accessed directly rather than through getters (there are a handful of getters, so I accept it's a bit inconsistent). In this case I think you have done this so that you don't have to add the parameter for the other instruments (as this overrides an abstract_inst
method that returns None
).
However there are a few things that maybe are worth discussing?
-
Is this parameter ever likely to be changed (if not it can be hard-coded as it is in
calibrate
)?
mantid/scripts/Diffraction/isis_powder/routines/calibrate.py
Lines 50 to 56 in 5096764
aligned_ws = mantid.ReplaceSpecialValues( InputWorkspace=aligned_ws, OutputWorkspace=aligned_ws.name(), NaNValue=0, InfinityValue=0, BigNumberThreshold=1e15, SmallNumberThreshold=-1e15, -
If we do want to add a parameter, as
ReplaceSpecialValues
is called in other places, is it worth having the same threshold for all instances? -
And in case of (2) perhaps this should be a parameter all instruments have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this parameter to deal with big data points caused by vanadium normalization. Yeah, I agree with you that it is called in multiple places and we need to make them consistent. This hard-coded ReplaceSpecialValues has been added recently by you. Why did you add it?
👋 Hi, @MohamedAlmaki, Conflicts have been detected against the base branch. Please rebase your branch against the base branch. |
329ee7e
to
4cbf00c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - thanks for this. Lets think about standardising the ReplaceSpecialValues
thresholds in another PR!
Description of work.
This PR implements absorption corrections in the OSIRIS scripts, which can be applied in two ways: Simple Absorption Correction and Paalman Pings Absorption Correction.
For Simple Absorption Correction, the
MonteCarloAbsorptionCorrection
algorithm is used to correct the workspaces. For Paalman Pings Absorption Correction, thePaalmanPingsMonteCarloAbsorption
algorithm is used.To enable absorption correction in the focus function,
absorb_corrections
parameter must be set to True. The user can select the absorption correction method by settingempty_can_subtraction_method
to eitherSimple
orPaalmanPings
.Here's an example of Simple Absorption Correction:
And an example of Paalman Pings Absorption Correction:
Since absorption correction can increase the intensity of peaks, it's possible to get very high values after applying vanadium normalization. To prevent this,
vanadium_normalization_cutoff
has been added. This parameter limits the maximum values for the counts after applying the vanadium normalization.To test:
Here is the testing script:
Contact me for the configuration and calibration files.
Fixes #34311.
Reviewer
Please comment on the following (full description):
Code Review
Functional Tests
Does everything look good? Mark the review as Approve. A member of
@mantidproject/gatekeepers
will take care of it.