Fix 120: Leading and trailing whitespace removed from sample position strings

[dehoni]

…before validation

Instrument(s)

All SANS instruments

Story/Acceptance criteria

As a user running do_sans or do_trans, I want that leading or trailing whitespace in sample position strings are ignored so that valid sample positions are still recognised and executed correctly.

Description of work

Updated sample position handling to strip leading and trailing whitespace from position strings before validation.

Issue/Ticket Reference

Fixes issues #120 #120

Tests

Describing the testing undertaken for this PR

To test

Existing behaviour for correctly formatted position strings is unchanged.
Sample position strings are corrected by removing leading and trailing whitespace before validation.
Inputs such as " 1CB" and "1CB " are treated as "1CB".
Invalid sample positions continue to be rejected after normalisation.
Position strings containing only whitespace remain invalid.

Code Review

• Is the story/acceptance criteria fulfilled?
• Is the code of an acceptable quality?
• Are the tests sufficient?
• Do the changes function as described and is it robust?
• Are the changes able to work across all intended instruments?

Final Steps

• Are there any changes to instrument configurations required?
• Are there any changes to instrument scripts required, e.g. change on script signature, default argument and have these been communicated?
• Does the script need to be deployed onto the instrument?

[Tom-Willemsen]

Did you intentionally include these changes to title= and thickness= and dae= parameters in do_sans and do_trans?

The changes are unrelated to the sample changer position-stripping logic and probably better belong in a separate change, if they are needed and wanted by all SANS instruments.

[dehoni]

Having no thickness might not play well with Mantid. The default is typically 1.0 if no other input is given. Also there were issues changing dae modes. This ensures that it always sets the default behaviour. You are right, it might be better in #122 .