Difference between revisions of "Best Practices/FAQ"
From Hall D Ops Wiki
(→Best Practices) |
(→Best Practices) |
||
| Line 6: | Line 6: | ||
** Every run should have at least a brief descriptive comment entered, even those taken by experts performing tests. | ** Every run should have at least a brief descriptive comment entered, even those taken by experts performing tests. | ||
*** Here is an example of a good comment for a production run: Radiator is JD70-119, PARA, Target Full, Mode 7, 200nA, 182 M events, good beam, occasional FSD trip, FCAL HV alarms, livetime ~90%, event rate ~ 30kHz, data rate ~600 MB/sec | *** Here is an example of a good comment for a production run: Radiator is JD70-119, PARA, Target Full, Mode 7, 200nA, 182 M events, good beam, occasional FSD trip, FCAL HV alarms, livetime ~90%, event rate ~ 30kHz, data rate ~600 MB/sec | ||
| + | * The run should be stopped before changing radiators or any other beam/detector conditions. Otherwise the information stored in RCDB may be incorrect. | ||
* '''Logbook Entries''' | * '''Logbook Entries''' | ||
** Each shift should have a summary entry where events and runs are logged, including all interactions with the MCC. Major events should also have their own log entries. A good example of a summary entry [https://logbooks.jlab.org/entry/3447161 is at this link]. | ** Each shift should have a summary entry where events and runs are logged, including all interactions with the MCC. Major events should also have their own log entries. A good example of a summary entry [https://logbooks.jlab.org/entry/3447161 is at this link]. | ||
Revision as of 20:36, 7 February 2017
Best Practices
- Run Control
- Every run should be begun starting at the "Configure" step in the Run Control GUI.
- Every run should have at least a brief descriptive comment entered, even those taken by experts performing tests.
- Here is an example of a good comment for a production run: Radiator is JD70-119, PARA, Target Full, Mode 7, 200nA, 182 M events, good beam, occasional FSD trip, FCAL HV alarms, livetime ~90%, event rate ~ 30kHz, data rate ~600 MB/sec
- The run should be stopped before changing radiators or any other beam/detector conditions. Otherwise the information stored in RCDB may be incorrect.
- Logbook Entries
- Each shift should have a summary entry where events and runs are logged, including all interactions with the MCC. Major events should also have their own log entries. A good example of a summary entry is at this link.
- The summary logbook entry should have a summary of at minimum the production run taken during the shift along with the number of triggers in each run and the radiator information.
- Data Quality Monitoring
- Approximately 10-15 minutes after the start of the run, the histograms displayed by RootSpy should be checked against the approved reference histograms. These histograms should be posted to the logbook, using the button on the RootSpy GUI.
- Once per day a harp scan should be run following the directions at this link. Note that the beam is expected to be Gaussian with sigmas in the range 0.6mm to ~1.2mm, but any action should be taken by the RC.
FAQ
What should I do if I can't find an answer
If you have a question that is not answered by this wiki, first look to the whiteboard in the counting house. If that does not answer your question, ask the RC.
