Subject: RE: Summary of Luminosity Index discussion Date: Mon, 6 Mar 2000 10:03:18 -0500 From: "Richard Partridge" To: , , , , , "Chyi Miao" , I have revised the summary based on two suggestions from Michael Begel: - At the meeting we proposed updating the luminosity index at begin/end stores. I have added this to the conditions causing a luminosity index update and to the list of things that need to be logged in Oracle. - A suggestion that the luminosity server communicate its status to the DAQ Monitoring program via ITC. I have added this to item 7. It also occured to me that the luminosity index should be updated on prescale changes. Last run, we required a data run to end before updating prescales, but that was a restriction some were unhappy with. I am not sure what the plans are for this run, but it seems like we should allow for this capability. The revised summary is given below. Please circulate any additions/corrections/comments. Rich --------------------------------------------------------------- 1. Since TCC knows about run conditions, it is in the best position to control luminosity index updates. 2. TCC will push "Luminosity packets" containing scaler and other information to the luminosity server using ITC. The following information will be included in a luminosity packet: - luminosity and livetime scalers (further work is needed to define exactly what scalers will be sent) - luminosity index number, tick, turn, and date-time stamp as described in "Proposed Luminosity Accounting/Tracking Procedure" written by Dean (23-April-1999) - packet number, initialized to 0 when TCC starts and incremented each time TCC tries to push data to the luminosity server (the luminosity server can use this index to tell if it missed a packet) 3. Luminosity packets will be sent to the luminosity server under the following conditions: - a run was started or stopped, causing the luminosity index to be updated - when more than a set period of time (currently thought to be 5 seconds) has passed since the last luminosity packet was sent 4. The luminosity index should be incremented under the following conditions: - whenever a store begins or ends - whenever a run is started or stopped - whenever prescales are changed - when a luminosity packet is to be sent to the luminosity server and more than a set period of time (currently thought to be 1 minute) has passed since the last luminosity index update. 5. TCC will put the current luminosity index in its data block and L3 will move the luminosity index to the event header where it can be accessed by the data logger. 6. A mechanism needs to be found to ensure that the luminosity index is unique throughout the life of the experiment. One possibility would be to periodically record the luminosity index in non-volatile storage, say every time the luminosity index is evenly divisible by 100. When TCC restarts, it could add 100 (200 to be safe?) to the value in non-volatile storage and write the new value of the luminosity index back to non-volatile storage. 7. Error handling and alarms need to be worked out. There was some thought that ITC might queue messages, which would help if there were short-term network interuptions. The luminosity server will communicate with the DAQ Monitor program to provide its status and signal alarms. 8. The following information needs to be recorded in the online Oracle database: - Luminosity scalers and time stamps (Luminosity Server) - The association between trigger names (or other trigger ID) and the trigger bit number (COOR?) - L1 Exposure group number for each trigger (is this info already in Elizabeth's L1 trigger tables?) - Prescales (COOR? are they allowed to change during a run?) - First and last luminosity index for each file (data logger) - First and last luminosity index for a store - Downtime tracking information (HV trip, etc.) acquired by COOR at start of run (COOR?)