Online and offline software overview, status and plans Status and Integration to STAR : Trigger DAQ Monitoring Slow Controls Online Databases Online/Offline/MC software 1

Trigger FMS (and FPD and FPDSMD) are all connected to QT boards and DSM Tree Full FMS/FPD trigger algorism document is available – High Tower Trigger – Cluster Sum Trigger – Multi Cluster Trigger – Module Sum Trigger (FPD) – LED trigger Test bed for new QT system (now used for other detectors) Full bit-wise check of DSM Tree (now covers all DSM tree) Plan : Already fully integrated Improvements (Jet Trigger with FHC) 2

DAQ All QT and DSM Tree are read by L2 FMS (and FPD/FPD-SMD) data are part of trigger data bank  DAQ file  Trigger Data file (with pre/post data) Trigger Data file analysis tool (trg2ntp) maintained by FMS group is essential and used by many subsystems Plan: Already fully integrated 3

Monitoring Status Few plots in Pplot as of run9 Because it samples only tiny fraction of data, it was almost useless Experts running monitoring/reconstruction codes on trigger data file ~min after run is taken Les’s online pi0 reconstrucitons (off TrgSscratch) Chris’s bitwise check (off L2) Hank’s monitor (off TrgSscratch) Len monitor ( off HPSS) Steve’s analysis ( off HPSS) 4

Monitoring Plan Improved Pplot to monitor LED signal Ensured bandwidth of LED trigger into EVPool (Jeff said its easy) This monitors everything : HV, gains, LED, Trigger and DAQ Unified and systematic/automated reconstruction codes running Bottleneck is getting data to RCAS disks (Trigger Data file -> L2- -> TrgScratch -> Online farm & HPSS) HPSS -> “ntuple”s on RCAS Bottleneck will be HPSS->RCAS disk speed, and diskspace Minimal CPU ~1min / 10k event file * ~50files / run * 50 run / day = 250 CPU min / day gzipped ntuples ~400 G byte from run9  User monitor codes (Like Len’s)  Reconstruction iterations (Like Les’s and Steve’s) Real-time fast stream MuDst with StTriggerData(raw trigger data) production??? (only if Jerome can be convinced after all those years) 5

Slow Control & Online DB Status Console/command-line based system (No connection to STAR SC) Large cells: Shell scripts to communicate with LeCroy 1440a small cells: PSU software to communicate with PSU HV motherboard Only expert(s) to turn on/off HV or change HV We do not turn on/off for beam dump/refill No HV trips to reset Zener Diode Issue HV Alarm = Les Bland (No alarm to STAR alarm handler) HV setting file on local disk QT-LUT-Gain file on trigger local disk HV log files on local disk every ~min = ~10 G bytes for run9 (no connection to Online DB) 6

Current FMS HV system fpd.daq.bnl.local fmsserv.trg.bnl.local (terminal server) LeCroy1440 cwcontrol.trg.bnl.local PSU Motherboard PUS Motherboard fpdswitch.trg.bnl.local (network power switch) 7 HV Operation Manual / Documentation / HV setting file & logfile location HV cable map QT-LUT-gain North Top Lg cells North Bot Lg cells South Top Lg cells South Bot Lg cells LVs South Sml Cells North Sml Cells

Slow Control & Online DB integration Plan No big change in HV system itself is planned It should remain “experts” only to operate HV (Zener Diode issue, no trip, no on/off while dump) Instruction to shift : Watch LED plots in Pplot, call expert if any change Do no turn on/off HV Who is “expert(s)” / who is allowed to change HV  See Les’s management talk Sending log-files to Online-DB is not essential and not planned – trg.bnl.local bandwidth issue – LED monitor will do most of the job – low priority, but if required, need ~2FTE month Messaging to STAR alarm system is not essential and not planned – It was stable (There was no HV trips) – LED monitor will do most of the job – low priority, but if required, need ~2FTE month 8

FMS reconstruction code Raw Data (Encoded QT data) Decoded QT data Hit (Mapped & Calibrated Energy) list Cluster list Photon list QT decoder Mapping & Calibration Cluster Finder Shower Shape fit MC cell list from GSTAR Summing, mapping Inverse-Calibration, Digitization & Calibration 9 We’ll have 1 st order calibration relatively quick (online pi0 reconstructions) Final calibrations with energy dependence (none-linearity) & run dependence comes much later User analysis Geometry & Cuts

Online and Offline Analysis code Status Trigger Data file DAQ file HBOOK ntuple (raw) BNL package StEvent (raw) MuDST (raw) HBOOK ntuple (raw + EMC/TPC) PSU package Calibration text files Geometry text files Map text files HBOOK ntuple (MC) Parameter text files ExperimentGSTAR (FPD & FMS geometry) PYTHIA with specialized filter 10

BEMC model DAQ file StEvent (raw + cluster + point) MuDST (raw + cluster + point) Offline DB (preliminary) EMC makers in BFC (DB + ClusterFinder + PointFinder) StEvent on memory (raw + cluster + point) MuDST on memory (raw + cluster + point) Offline DB (updated) Mudst2StEvent + EMC makers ExperimentGSTAR GSTAR file g2r 11

Online and Offline Analysis code Status Trigger Data file and ntuple from GSTAR  Analysis is NOT just “online” monitoring Large volume of this analysis is happening just (~min) after run is taken Used as “online” monitoring Used as feedback to HV/LUT gain Used as “offline” analysis for inclusive physics results, up to final papers MC saves many CPU hours by not simulating particles into mid-rapidity/east MuDST file  Analysis MuDST is produced ~months later Used for FMS-TPC or FMS-BEMC correlation analysis 12

Online and Offline Analysis code Status BNL & PSU packages are based on the same reconstruction code (“Yiqun’s code”) - Some differences because improvements made since code was split - BNL package = fortran/hbook+paw wrapped + New cluster finder (Ermes’s work) for hole treatment + Energy dependence/Run dependence corrections + SMD reconstruction Code is available : rcas://hank/put/the/file.tar - PSU package = c++/root wrapped + Code cleanup/re-organization + New cluster finder Code is available : rcas://Steve/put/the/file.tar 13

Analysis Code Plan Preserve “Trigger Data file analysis” path – Established user codes/scripts – Light weight for quick turn around (Concern on speed / overhead if we switch) We want one code to do “trigger data file analysis”, “MuDST analysis” and “MC analysis” – Re-merging “reconstruction (yiqun) code” in BNL and PSU package – One code in CVS, included in both Makers and “BNL/PSU packages” – Separate cluster finder and shower shape fitting – Add options/switches to have different code/versions Define classes in StEvent/MuDST for – Raw Data – Hit (Mapped & calibrated energy) list – Cluster list – Photons list Map, Geometry and Calibration in DB g2r (Never needed correlated MC sample so far) Man power 14

Plan Trigger Data file DAQ file HBOOK ntuple (raw) BNL package StEvent (raw) MuDST (raw) HBOOK ntuple (raw + EMC/TPC) PSU package Calibration text files Geometry text files Map text files HBOOK ntuple (MC) Parameter text files ExperimentGSTAR (FPD & FMS geometry) PYTHIA with specialized filter 15

Plan DAQ file StEvent (raw + cluster + photon) MuDST (raw + cluster + photon) Offline DB (preliminary) FMS makers in BFC (DB + ClusterFinder + Photon Fit) StEvent on memory (raw + cluster + photon) MuDST on memory (raw + cluster + photon) Offline DB (updated) Mudst2StEvent + FMS makers ExperimentGSTAR GSTAR file g2 r Trigger Data file Trigger data file reader 16

Online Package(s) Plan StEvent (raw) MuDST (raw) FMS analysis Maker(s) (Hit + Cluster + Photon list) Cluster Finder Trigger Data file HBOOK ntuple (raw) Shower fit MuDST on memory (raw + hit + cluster + photons) Offline DB text files GSTAR GSTAR file g2 r DAQ file Experiment 17

Summary of FSM integration plan Trigger - Done DAQ - Done Monitor – LED Slow Control / Online DB – No need Software – Unify to one code – Preserve “fast” path – Bring FMS raw data, HIT, Cluster and Photon to MuDST 18

Backup 19

Analysis Code Plan FTE monthProsCons Plan10No work … Not integrated … Plan26???Fully Integrated … A lot of work Filesize … Plan32???Less work Maintain “current” path A step towards plan2 … … 20