Online Monitoring bei CDF für Run II (2001)

T. Arisawa2, A. Heiss1, G. Barker1, M. Feindt1, F. Hartmann1, Kouji Ikado2, Kaori Maeshima3, S.

Menzemer1, Th. Müller1, D. Neuberger1, K. Rinnert1, P. Schemitz1, A. Skiba1, H. Stadie1, G. Veramadi4, H.

Wenzel1

1 Institut für Experimentelle Kernphysik – Karlsruhe

2 Waseda University, Tokyo 169, Japan

3 Fermi National Accelerator Laboratory, Batavia, Illinois, USA

4 Ernest Orlando Lawrence Berkeley National Laboratory, Berkeley, California, USA

DPG Tagung Dresden 20-24.März 2000

Was ist ein Consumer Monitor ?

•Consumer überwachen die Datenintegrität des Experiments in Echtzeit.

•Consumer Monitore sind Module des CDF Offline Framework (AC++)

•Bsp.: Trefferraten ‚Occupancy‘ (tote/‘heiße‘ Kanäle); Trigger Raten; Logik, Luminosität; Level-3 Rekonstruktion; Vertex Positionen; Physikalische Rekonstruktionen; etc...

Die einzelnen Monitore werden in Zusammenarbeit mit den Experten der verschiedenen Detektorsysteme programmiert.

Consumer Server, Consumers und Display Server

Die verschiedenen Elemente des Frameworks

• Error Handler

• State Manager

Consumer

Server

Display/Browser

Datenfluß

Datenfluß

I. Consumer

• Analyse der Daten und Integritäts-Kontrolle ohne die Datennahme zu beeinflussen.

• Sicherung der Resultate im ‚Shared Memory‘ (TMapFile).

• Mehrer verschiedene Monitore können kombiniert werden oder auf getrennten Rechnern (CPU) laufen (Flexibilität).

•Monitor und Anzeige werden getrennt behandelt, die Wiederholfrequenzen werden nur durch die Netzwerk-Bandbreite bestimmt (nur kleine Objekte werden übertragen, z.B. Histogramme).

• Wird von den Experten programmiert.

• Wir erleichtern die Realisierung und den Start.

• Einfacher Zugang zu aktuellen und archivierten Daten (Vergleich).

I. Consumer (Unser Beitrag)• Automatisiertes Script erzeugt oder modifiziert:

1. Makefiles

2. Monitor Header, Templates und Sourcen

3. Modul zur Integration in das CDF Offline Framework (AC++)

4. tcl Script für einen Testjob

5. und bindet alles in die CDF Software Strukturen ein.

• Gut dokumentierte Beispiele

• WWW Seiten mit Projektinformationen und den Programmen http://kcdf1.fnal.gov/~wenzel/consumer_new

I. C

onsu

mer:

D

esi

gn

& B

est

an

dte

ile

II. Der Server

•Auslese der ROOT Objekte aus dem ‚shared Memory‘

•Verteilung via Socket Verbindungen zu verschiedenen Display/Browsern (lokal und remote)

•Zugangsberechtigung

•Statusinformationen werden im WWW angezeigt

III. Das Display

• ROOT basierte Grafische Benutzeroberfläche GUI

• Daten via:

1. Server socket Verbindung

2. TFile

3. TMapFile

IV. Error Handler & V. State Manager

IV. Error Handler: Ein Kandidat ist das ZOOM II Error Logger Softwarepaket (http://www.fnal.gov/docs/working-groups/fpcltf/fpcltf.html#ErrorLogger)

V. State Manager•Anzeige und Kontrolle des Status eines jeden Consumers•Error Report; Kommunikation mit Run_Control

Warum Root? Probleme! WünscheRoot stellt viele nützliche C++ Klassen zu Verfügung:

1. Socket Verbindungen: Server und Clients

2. Shared Memory

3. Analyse Werkzeuge (Hochenergiephysik)

4. GUI

Wünsche:

1. Bessere Fehlerbehandlung

2. Besserer Graphischer ‚Baukasten‘

Probleme:

TMapFile: Memory mapping; Ineffizienzen in Speichernutzung und Geschwindigkeit; kein Dateiverzeichnisstrukturen

Status

• Prototypen aller Komponenten existieren und sind getestet.

• Datenübertragung funktioniert.

• Momentan werden die endgültigen Programme für Run II realisiert.

• Die einzelnen Consumer Monitore werden mittels der zur Verfügung gestellten Hilfsmittel realisiert.

• Die existenten Programme werden für die Inbetriebnahme (Commissioning) und bei einem Test mit kosmischer Höhenstrahlung verwendet.

• Dokumentation und Tutorien existieren im WWW.

• Der weitere Erfolg hängt von der allgemeinen Akzeptanz ab (bisher gutes Feedback)