mantid icon indicating copy to clipboard operation
mantid copied to clipboard

Incorrectly rounded values used in SANS reduction

Open gemmaguest opened this issue 2 years ago • 4 comments

Original reporter: @rmdalgliesh @smk78

Description

Some values entered into the SANS GUI are rounded for display. This is fine in terms of the display, but they are also then written back into the model and used in the reduction, causing different results than expected. We should always use the original, un-rounded values in the reduction. See the table below for a list of affected values.

Steps to reproduce

  • Open the ISIS SANS GUI
  • Load this user file: MaskFile_rounding.zip
  • Enter a run number in the first cell in the table, e.g. 74044
  • Click Settings on the left and then go to the State Diagnostic tab. Click Update.
  • Compare the values in the state to those in the TOML file to see if they are rounded or not
    • use the reference table below to see how names relate to each other
    • note that you can export the state diagnostic to a .json file using the Save button on the tab if it is easier to check in a text editor
    • note that there are some good online tools available for comparing json strings if you want to compare different state objects, e.g. jsonformatter
    • note that some values are only rounded if the option is enabled in the GUI, e.g. Q resolution values

Affected values

  • This table details which values are rounded and to how many decimal places.
  • Note that rounding is done in metres, as specified in the toml file and json state object; they may be displayed as mm or cm in the GUI instead.
  • The minimum required dp, if given, is from an email from @smk78; it looks like we are meeting this minimum at least, although it would still be more correct to use un-rounded values.
TOML name State name dp in m required dp
instrument.configuration.sample_offset move.sample_offset 4 4
instrument.configuration.sample_aperture_diameter convert_to_q.q_resolution_a2 4 4
binning.1d_reduction.radius_cut convert_to_q.radius_cutoff 4
q_resolution.delta_r convert_to_q.q_resolution_delta_r 4 4
q_resolution.source_aperture convert_to_q.q_resolution_a1 4 4
q_resolution.q_resolution_h1 convert_to_q.q_resolution_h1 4
q_resolution.q_resolution_h2 convert_to_q.q_resolution_h2 4
q_resolution.q_resolution_w1 convert_to_q.q_resolution_w1 4
q_resolution.q_resolution_w2 convert_to_q.q_resolution_w2 4
transmission.monitor.M4.shift move.monitor_4_offset 4
transmission.monitor.M5.shift move.monitor_5_offset 4
detector.radius_limit.min mask.radius_min 4
detector.radius_limit.max mask.radius_max 4
detector.configuration.rear_centre.x move.detectors.LAB.sample_centre_pos1 6 6
detector.configuration.rear_centre.y move.detectors.LAB.sample_centre_pos2 6 6
detector.configuration.front_centre.x move.detectors.HAB.sample_centre_pos1 6 6
detector.configuration.front_centre.y move.detectors.HAB.sample_centre_pos2 6 6
detector.configuration.all_centre.x used for rear/front if not given 6 6
detector.configuration.all_centre.y used for rear/front if not given 6 6

gemmaguest avatar Jan 04 '23 18:01 gemmaguest

The email from @smk78 had these questions. I've put comments in to answer whether they are rounded or not.

  • Min precision should be 3 dp for these, 4 dp would be better:
[instrument.configuration]
    sample_offset               # 4dp in m
    sample_aperture_diameter    # 4dp in m
  • All 3 of these should be to 6 dp:
[detector.configuration]
    all_centre    # 6dp in m
    front_centre  # 6dp in m
    rear_centre   # 6dp in m    
  • Out of curiosity, to what precision are these read??? we routinely enter values in the User File to 4/5 dp:
    front_scale                 # not implemented; see https://docs.mantidproject.org/nightly/techniques/SANS-Toml-v1.html#set-scales-a-b-c-d-e
    rear_scale                  # scale.scale; not rounded
  • We are entering some of these to 5 dp, are they all being used?
[detector.correction.position] # none of these are rounded
    rear_x
    rear_z
    front_x
    front_y
    front_z
    front_rot
    front_radius
    front_side
    front_y_tilt
    front_x_tilt                
  • Min precision should be 3 dp for this, 4 dp would be better:
[mask.spatial.beamstop_shadow]
    width                       # not rounded
  • Min precision should be 3 dp for these, 4 dp would be better:
[q_resolution]
    source_aperture    # q_resolution_a1, 4 dp in m
    delta_r                     # q_resolution_delta_r, rounded to 4dp in m

gemmaguest avatar Jan 04 '23 18:01 gemmaguest

sample_centre_pos2 appears to be rounded to -0.004 in the GUI instead of -0.0037 as used by the ICI. Seems to be an issue with how it's taken from the user file? This is interfering with the reduction.

cailafinn avatar Mar 07 '23 15:03 cailafinn

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] avatar Oct 09 '23 00:10 github-actions[bot]

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.

github-actions[bot] avatar Oct 16 '23 00:10 github-actions[bot]