Skip to content

Muons: TPar improvements #8990

Description

@GRyall

Feature Description

As a muon scientist, I would like for the TPar file to be overwritten each time I load a configuration with a known good one for that configuration. This will help prevent lost time from users doing silly things.

Explanation

Scripts used by muon instruments make use of a TPar file. This file contains a list of parameters that defines how certain temperatures are reached. Users sometimes edit this file for a given experiment (particularly for MuSR). This then means that for the next experiment the file is wrong. Scripts exist to make use of git to restore it, but this relies on someone spotting it has changed.

Additional Information

  • The format of the TPar file is constant, though the number of lines varies
  • There are two TPar files used the regular one and the booster one
  • The set temperature script and possibly script generator consume the tpar file
  • There is currently a tpar editor as a device screen in the GUI
  • Not every instrument wants to expose tpar editing to it's users
  • A valid TPar file:
    • containers a header. This is never changed
    • Has a constant number of columns
    • THigh is the TLow of the next line
    • has at least one line that is not header

Acceptance Criteria

The following are the minimum requirements for this ticket:

  • When a configuration is loaded, the relevant par files are overwritten with a master copy. The master copy should not be readily available to users.
  • The tpar gui text editor is updated to reflect this workflow and become the only place users are signposted to edit files. This editor points at the in use copy and allows for it to be overwritten. A tab provides a switch with the booster tpar file.
  • This work should be presented to the Muon scientists to check it meets their needs - we have been around this too many times to wait until the release to find it needs another tweak

Once complete this work should be patched to MuSR, ideally for the upcoming cycle.

How to Review

Before making a PR...

  • Provide verbose instructions for the reviewer to test your changes
  • Describe how you have implemented testing for this feature
  • Provide screenshots of the feature to help the reviewer if relevant

If not applicable, write "Not applicable"

...

To the reviewer: Make sure to update submodules!

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status
Review

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions