Run plan » History » Version 467

Version 466 (Pip Hamilton, 12/19/2017 12:44 PM) → Version 467/1516 (Pip Hamilton, 12/19/2017 12:44 PM)

h1. Run Plan

h2. Contacts

|_. Contact |_. Number |_. Alt Number |
| Shifter | 1 (937) 582-6663 | 1(937) 5-UBOONE |
| Backup Shifter | 1 (978) 822-2582 | 9788 BACK UB |
| *ON-CALL:* RunCo (Pip) | 224 253 2345 / +44 7908 320 078 7908320078 (UK number) | |
| *ON-CALL:* Deputy RunCo (Adrien) | 630 544 9094 | |

[[SLC_-_Guide#Which-expert-to-call-for-which-alarm| Link to which experts to call in case of other alarms]]

h2. Run Configuration

h3. Summary

We are currently taking beam data with run config **681**. All runs should be set to go for 420 minutes.

Please inform runcos ASAP of any information you receive from MCR about the beam.

Please do not forget to check your runs in the RunCat.

h3. Run Control

|_. Configuration |_. Config ID |_. Time [min] |
| PHYSICS_BNB_NUMI_MUCS_EXT6990mHz_SWTrigger_2Stream_LowThreshold50_c2 | 681 | 420 |

h2. Notes on current operations:

* *Before resetting the PUBS, please ensure there are no PUBS errors being displayed* - if there are, please report this to the Data Management expert (via email) before resetting.
* The sn_read_lag error is currently our most frequent DAQ alarm. This alarm will appear as a symptom of runs ending; if it clears when the new run begins there is no cause for concern. If you see the alarm appear during an ongoing run, follow the instructions on the Run Control Troubleshooting page ( - near the bottom).
* There is a known problem with the uBooNE RWM readout. If you see that the beam timing from the RWM is bad, you can still mark the run as good (although please still email runcos + Zarko to tell them you saw this). Check the beam timing plots in the OM to ensure that it's only a small proportion of events outside the alarm limits.
* CRT Crate Rails alarms (uB_CrateRails_CRTUtil*) can be ignored until this line is removed from the run plan.
* The purity monitor is currently off - don't be alarmed if its plots show no recent updates.
* If you should see anything that indicates the LArTF network is not responding (DAQ machines not responding, many INVALID alarms in slow controls), contact the runco immediately.
* We've been seeing frequent mem_free errors on seb06. If the error is minor then there is no need to call the DAQ expert on this front - just send them an email at the end of your shift noting the frequency at which you saw this alarm. Please do not acknowledge it however.
* Please note that the password of the expert call list was modified recently, and is not the same as the one for DocDB, it is now "$uBneutrino!"

h2. Additional Shifter Requirements:

* Please follow the [[Shift_turnover]] procedures
* At the end of your shift, please post a plot of the last 8 hours of variable: uB_Cryo_IFIX_1_0/PT102
** Minor oscillations below 0.1psig are indicative of the LN2 dewar refilling. This is normal.
** A small spike every 7 hours is expected. Example:
* During access to the detector:
** Please fill out a Beginning of Detector Access and End of Detector Access Form.
** If the "keytree" alarm occurs, and the persons accessing the platform have not called the shifter first, then call LArTF to find out who is accessing the detector. If no one answers, call the runco.
** Detector platform access must be cleared by runcos.
** At the end of detector access, please acknowledge the keybank incomplete alarm.

h2. In Case of Cryo Alarms

All the cryo related alarms from either iFix or slow controls should be documented by shifters in ECL with the alarm variable names.

If a shifter does not receive a call within 15 minutes of seeing a MAJOR cryo alarm:
* Call the Run Coodinator
* If the Run Coordinator cannot be reached
** During Daytime Operating Hours (8am - 10pm CDT)
*** Call the cryo experts in the order listed on the expert call list:
** During nighttime hours:
*** Email the cryo experts