Run Meta-data Flags¶
This is to define the Run meta-data flags also known as "Data Quality Flags"( #1383 ).
The table below defines the meaning when set of each flag within the bit-field, with reference to some specified DAQ run. The underlying implementation may split these among multiple separate fields.
There are only 31 bits per word as Java (up to 1.7 inclusive) only has signed
|0||async||Data Mover Succeeded||Data copied to CASTOR and registered in LFC|
|1||async||File Compactor has run|| Script completed successfully:
|2||async||Tarball exists|| Data volume sufficient:
|3||async||RESERVED||In case we need this field later|
|32||RESERVED|| Java only has signed
|60||SOR||MICE Target is dipping||
|61||EOR||ISIS not tripped||e.g. no beam current alarms during run|
|62||SOR||ISIS running||e.g. Beam Current over some threshold at run start|
|63||RESERVED|| Java only has signed
Key: bold - confirmed; normal - draft; italics: proposed but we might not know how to do it yet...
SOR - start of run; EOR - end of run; async - some other process (these to be updateable)
Bits 0-3 may be re-written if there is an intermittent failure of say the File Compactor and it is later re-run by hand; the standard API for these should allow update/overwrite.
Bits 4-63 should only be written once by Run Control; there will be a separate expert API for corrections. If this is a multi-step operation then it must be specified which bits are updated at each step. This should be enforced by bit-masks at the lower level?