BNMR: Run numbering: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
en>Suz
mNo edit summary
en>Suz
mNo edit summary
Line 33: Line 33:


;NOTE
;NOTE
The MIDAS logger {{Utility|name=mlogger}} opens the data file at the start of each Type 1 run (see [[BNMR: Data Logging|Data Logging), before anything else runs. The only exception seems to be the check on whether a [[BNMR: Programs page#Required client|Required client]] is running. Therefore, performing a run number check at the beginning of run is too late to prevent the data file being opened for Type 1 runs. This is the case for a client running with the earliest possible  
The MIDAS logger {{Utility|name=mlogger}} opens the data file at the start of each Type 1 run (see [[BNMR: Data Logging|Data Logging]]), before anything else runs. The only exception seems to be the check on whether a [[BNMR: Programs page#Required client|Required client]] is running. Therefore, performing a run number check at the beginning of run is too late to prevent the data file being opened for Type 1 runs. This is the case for a client running with the earliest possible  
[https://midas.triumf.ca/MidasWiki/index.php/Run_States_and_Transitions#Run_Transition_Priority transition sequence number] as well as the  
[https://midas.triumf.ca/MidasWiki/index.php/Run_States_and_Transitions#Run_Transition_Priority transition sequence number] as well as the  
[[BNMR: Perlscripts#at_start_run.pl|at_start_run]] script. Therefore, the ODB key in the mdarc subtree [[BNMR: mdarc#enable prestart rn check|enable prestart rn check]] must always be set to "n" (the default).
[[BNMR: Perlscripts#at_start_run.pl|at_start_run]] script. Therefore, the ODB key in the mdarc subtree [[BNMR: mdarc#enable prestart rn check|enable prestart rn check]] must always be set to "n" (the default).

Revision as of 15:57, 16 November 2018

Introduction

bnmr and bnqr experiments use the MUSR run number scheme, whereby runs are designated as "Real" or "Test" according to their run number. Data is always logged (saved to disk). 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). #Automatic selection of the run number (the default) must be enabled for the bnmr and bnqr experiments.

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.

NOTE

The run type cannot be switched using these buttons if #Automatic selection of the run number has been disabled.

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

For the bnmr and bnqr experiments automatic run numbering must be enabled, i.e. the key disable run number check must be set to "n" (default value).

Because bnmr and bnqr experiments use the standard MIDAS logger only for Type 1 runs, this adds complication to the automatic selection of the run number. 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.

The selection of the next run number is done automatically, controlled by the perlscript get_next_run_number.pl. This script is called by the custom data archiver mdarc after the end of each run, and indirectly by the Test and Real buttons on the BNMR: Custom Status page.

NOTE

The MIDAS logger mlogger opens the data file at the start of each Type 1 run (see Data Logging), before anything else runs. The only exception seems to be the check on whether a Required client is running. Therefore, performing a run number check at the beginning of run is too late to prevent the data file being opened for Type 1 runs. This is the case for a client running with the earliest possible transition sequence number as well as the at_start_run script. Therefore, the ODB key in the mdarc subtree enable prestart rn check must always be set to "n" (the default).


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.