1 / 5

The LHC Data Quality Flag

The LHC Data Quality Flag. C. Zampolli Offline Weekly Meeting 27 Jun 2011. See also https:// indico.cern.ch / conferenceDisplay.py?confId =124527. Outcome of the meeting on Thu 16 June.

levi-campbell
Download Presentation

The LHC Data Quality Flag

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The LHC Data Quality Flag C. Zampolli Offline Weekly Meeting 27 Jun 2011 See also https://indico.cern.ch/conferenceDisplay.py?confId=124527

  2. Outcome of the meeting on Thu 16 June • The data quality flag concerns the communication between the DIP servers and the DCS client, and the PVSS project, not the reliability of the values themselves • It is only one flag summarizing the "OR" between the various servers. In detail, the Data Quality Flag is TRUE if : • the lhc_instrumentation host is connected, • 6 LHC DIP Servers are alive, • 3 DIP Managers are running, • 3 Control Managers are up and running; • Each server is in fact responsible of a different subset of DPs, which is anyway not fixed --> can change in time C. Zampolli

  3. Outcome of the meeting on Thu 16 June • It is not possible to easily implement changes in the framework so to be able to associate a server to the DPs it is reading • Invalidatinga priori the whole data only according to this flag is not to be considered a good solution • the data quality flag MUST be 1 at the beginning of the run --> under discussion with Run Coordination • the flag will be stored in both the GRP Data (--> here we have the info to reconstruct the run) and the LHC Data (--> here we have the info for analysis, e.g. luminosity) objects in the OCDB, with its changes only (values will be published only on change). C. Zampolli

  4. Outcome of the meeting on Thu 16 June • If the flag turns to false during the run: the data will be reconstructed provided that the flag was TRUE at the beginning (to be confirmed, see point 6). However, an appropriate information should be stored in the ESDs, and in the AODs, so that each analysis that depend on the data coming from LHC can decide by itself whether to considered the run (or eventually each single event) as good for themselves. Obviously, this scenario can be followed provided that the cases when the flag becomes FALSE are very rare, otherwise too many data would be lost. Note that since the reconstruction depends on these data from values that should not vary during the run (e.g. energy and beam types), the fact that the flag was TRUE at the beginning of the run assures that the values read at first are reliable. This also because no change should occur at all during the run for these data. In this way, it is possible to reconstruct the run. Nevertheless, the presence of any FALSE value for the data quality flag may invalidate the data according to each analysis, following what was previously said. • In the GRP Data object, track of the changes will be stored; in the LHC Data object, for each value, a dedicated bit will contain the information concerning the quality flag. C. Zampolli

  5. Moreover… • The changes in the GRP pp to build the Beam Type are ready to be ported to the Release • Discarding the previous way? Or using it as a cross-check? C. Zampolli

More Related