isisneutronmuon/instrumentscripts

Instrument GENIE-Python Scripts

instrumentscripts's Issues

Account for uncertainty in fits

Currently, the fit function of the Fit class does not have any awareness of the uncertainty values on the measurements. Pass this additional information into the fit and update the classes to account for the uncertainty weighting in their calculations.

Discussion: Remove populate

As a developer I would recommend getting rid of populate

Its purpose is to create variables which can be used instead of block names so that scan can be written: scan(block, ... instead of scan("block", .... But it comes with caveats that when the user changes config they must remember to rerun populate to get new blocks and it is different to the recommended way of running g.cset i.e. cset("block", value). However I do not know the history and so would like to understand its motivation.

Acceptance Criteria

1. A decision is made on populate and the decision is recorder.
2. Any needed tickets are generated to make the changes

Increase ErfFit precision

The number of decimal places on the result of the ErfFit is too small in some cases and should be increased.

Perhaps the precision of the result could be informed by the fit error?

Centre of Mass Fit Line Colour

The line created on a plot by a CentreOfMassFit is blue which makes it blend in with the rest of the data. It should be plotted in orange to make it stand out in the graph (same as all the other fits).

Insist on improving fits when new data is added

scipy.curve_fit can wander down the garden path and produce a terrible fit on rare ocassions. This is all the more frustrating when the user previously had a perfectly good fit that has been overwritten by the poor one. The fitting routines should ensure that each subsequent fit is better than the old fit (accounting for the latest data) and keep the old fit if it was working out better.

Caching from the detector

Currently, the scanning routine call the detector object on each pass through the loop, but the only context that they are given is the requested measurement time. We should add an extra function parameter and return value that acts as an accumulator. This is a fairly generic framework, but would allow for the detector to maintain state for future calls without abusing global variables.

The help for the scan command does not mention how to change detector channels

Sometimes the user will want to scan on a value besides the main detector. While it is possible to do this, the explanation is buried deep in the middle of the tutorial. Even then, it's not particularly well explained. If the user runs

>>> help(scan)

The docstring will provide NO guidance on the issue.

Add Monitor and Detector numbers as parameters on Scan command

As a user, I would like the ability to easily specify which monitors should be used for data normalization. This should be done by adding parameters on the scan command so you can specify e.g.
scan("axis", -1, 1, count=11, monitor_number=1, detector_number=2)

Acceptance Criteria

• Monitor and detector number can be specified as arguments on general scan command
• Refactor defaults implementation in technique.reflectometry.refl_scans to use generic scan command

Prevent useless wiring table changes in SANS

Originally, the SANS library stored the current DAE mode so that changing into the current mode could be implemented as a no-op. This functionality was removed because a user changed the wiring table outside of the SANS library and chaos ensued trying to get the library back in sync with reality. It was also felt that changing the wiring table was quick enough to warrant the extraneous changes.

Unfortunately, that decision was premature and changing the wiring tables is becoming a serious bottleneck. Furthermore, changing the wiring table outside of the SANS library during a SANS experiment is unjustified enough that users attempting it will only have themselves to blame for the problems that follow.

Therefore, we should re-implement the caching.

Make Fit Result Easily Accessible

As a user I would like a convenient way to access the result of the last fit (e.g. peak, centre of mass, depending on type of fit). Something akin to ReplayScan, but for the Fit (although I believe we really are only interested in a single value rather than the whole Fit object).

Return Fit Error

The user should be made aware of the fitting error so they can more easily assess how accurate their result is.

• Return the error in the fitting object
• Display the value of the fitting error on the plot window

Do not overload set_pv

Currently, the SANS package overloads the set_pv function in the global namespace. Don't let this happen, as it can break other scripts.

Units and Labels on Scan Graphs

• Scan graphs should be plotted with units on both x and y
• Y axis should be labeled; ideally this should tell you the spectrum number, but I/I0 is fine too

Allow Setting Scan File Output Directory

Users should be able to set the directory where output files from scans are created. This should be changeable via a command.

Make Scan Over Blocks Case Insensitive

Block names used in a scan should not be case sensitive.

Note that ISISComputingGroup/IBEX#4136 will introduce an all uppercase alias for all blocks, which can be used for this purpose.

Keep scan plots in a single plot

It's possible to get multiple plots going with the scanning system, which can end with the user being forced to scroll through the plots to find the one that they are looking for. The scanning subsystem should ensure that there are no other plotting windows open.

Users want to be able to easily resume aborted runs

The user is performing an experiment with the following script

do_sans("Empty Cell", "AT")
do_sans("H2O", "BT")
do_sans("D2O", "CT")

During their run, they want to make some changes to the sample changer. In the middle of the H2O run on BT, they hit Ctrl-C to stop the script, go into the sample area, and make their changes. They then modify their script

# do_sans("Empty Cell", "AT")
do_sans("H2O", "BT")
do_sans("D2O", "CT")

As it currently stands, the script will immediately fail, detecting that the instrument is still running and admonishing the user to end the current run. Instead, we would like for do_sans to detect that the request run is already in progress and allow it to continue.