BNMR: Run numbering
Introduction
bnmr and bnqr experiments use the MUSR run number scheme, whereby "Real" runs are assigned a run number in a certain range depending on the beamline. All "Test" runs have a run number selected from the test run number range (independent of beamline). This means that the selection of the next run number is controlled by software (see #Automatic selection of the run number).
User selects TEST or REAL run
Prior to starting a run, the user can switch the run type on the custom Status page to select either a TEST or REAL run by pressing the appropriate button. These buttons are custom script buttons, which call perlscripts real_run.pl or test_run.pl to change the run type. The next run number for the appropriate run type (Test or Real) is then selected.
Run Number Ranges
The following run number ranges have been assigned:
- BNMR
- 40001 - 44499 inclusive
- BNQR
- 45001 - 49999 inclusive
- test
- 30001 - 30499 inclusive
Automatic selection of the run number
The selection of the next run number is done automatically, controlled by the perlscript get_next_run_number.pl. This script is called by mdarc which saves the data, and indirectly by the test and real buttons on the BNMR: Custom Status page.
Without the automatic checking, duplicate runs between I-MUSR and TD-MUSR and holes in the run numbering are inevitable. To preserve the automatic run numbering scheme, users are prevented from editing the run number.
User prevented from editing run number
By default, the MIDAS system allows the user to edit the run number at the begin-of-run. MIDAS provides a way of preventing editing of the run number. This is implemented in the ODB of both the bnmr and bnqr experiments, e.g.
[local:bnqr:Stopped]/>ls "/experiment/Edit on start/Edit run number" Edit run number n
Determine the Next Run Number
The perl script get_next_run_number.pl determines the next valid run number by examining the files in the saved file directory.
The archive directory is ignored at this time, as archive files are not considered at all during the run number check.
The ODB Key BNMR: Keys in /Equipment/FIFO_acq/mdarc ODB subtree#run type is used to determine if the next run is to be a test or a real run. This key is set when #User selects TEST or REAL run. is used to determine if the next run is to be a test or a real run.
For test runs, the script finds the file with the most recent run number in order to determine the next run number. Test run numbers are recycled, i.e. if the next run number would have been 30500 (i.e. greater than the maximum permitted), it will become 30000 . Any existing old saved files for run 30000 would be lost.
For real runs, the script finds the file with the highest run number, and checks that it is the most recent. It will also send a warning message if it finds any holes in the sequence of run numbers.
Type 2 (TD-MUSR)
The perlscript get_next_run_number.pl is designed to handle all possible situations for Type 2 (TD-MUSR) --- one of the most complicated being where a run is in progress where intermediate saved files are already present. This may occur if the custom data logger mdarc is stopped (or crashes) and is restarted during a run. In this case, it will continue with the run number unchanged, providing the present value of the run number is the same as that of the intermediate files. If the run number has been changed, it is assumed that is is unsafe to continue the run, and that the last saved run has been abandoned, so the next valid run number is assigned.
Type 1 (I-MUSR)
- NOTE
- the following may not be true any more now that the transition sequence number can be set
Due to the constraints of the existing midas logger mlogger, the automatic run number check is not as fool-proof for Type 1 as Type 2. This is because mlogger opens the data file for a run BEFORE the "prestart" transition, so the data file is opened before any checking can be done. Therefore the run number cannot be changed on start of run. This is not the case for Type 2, since mdarc does not open the data file until after the run number check procedure.
To minimize problems with the run numbering for type 1 runs, about 5s after the end of any run, a run number check is done automatically bymdarc. If this run number check fails, a second check will be done at the start of the run, and if this fails, the run start will be prevented.
However, it is a good idea for the user to press the TEST or REAL user button prior to starting a run if the last run failed, or for the first run after the logger is re-enabled after having been disabled for some runs; for this reason a test run number is required during runs with the logger disabled.
Problems with automatic run numbering
Most problems occur when running a Type 1 experiment, due to the constraints imposed by the Midas Logger, which has to open the log file prior to anything else (see above). This means the run number check cannot be done prior to opening the run file. For this reason, a run number check is now run automatically by mdarc about 5s after the end of each run. It warns the users if there is likely to be a failure at the next run start due to run number problems, and they should take steps to fix the problem.
Holes in run numbering
Holes usually occur in the run numbering sequence because the automatic run number checker was disabled by the user. They can also appear for Type 1 runs because the previous run start failed, and no run number check was performed (either automatically by mdarc or by the user pressing the TEST/REAL button) prior to starting the next run. Holes in the test run numbering sequence do not matter; holes in the REAL run numbering sequence are annoying for Donald's data archive.
Run number is set to 0 or 1
This can happen after a failure to access the odb; it seems to be a bug in Midas. It should be fixed by a later version of Midas. There is now a test in the alarm system that should prevent a run being started with this run number. Reset the run number by pressing the TEST or REAL user button on the midas main status page prior to starting the next run.
If a saved file has already been generated in the saved directory, with an illegal run number, the run cannot start until it is deleted/renamed. If it is empty (size 0) delete it, and reset the run number (TEST/REAL button). If it is not empty and may contain good data, rename both the .mid and .msr saved files to something else or move them into a subdirectory. Failure from run number checker Most problems are due to a failure of the previous run start (particularly for Type 1 (Integral). The post-stop run number check now performed by mdarc should alleviate some of these problems.
More information about the problem is available in the relevent output perlscript text file, e.g. for run numbering , most of the info is in the file /var/log/midas/<beamline>/get_next_run_number.txt. This may by hard for users to interpret, but is very useful to experts. More information on troubleshooting perlscripts is available by clicking here.
Fixing problems may involve deleting empty saved files (size 0) or renaming/deleting others with illegal names.
Note that the mdarc parameter "disable run number check" has been provided ONLY as a final resort when there are insurmountable problems with the automatic run numbering. You are strongly advised to fix any problem with automatic run numbering (or consult an expert) rather than disabling the run number check, since it can cause such problems as illegal or duplicate run numbers.