Online and offline software overview, status and plans
Status and Integration to STAR :Trigger
DAQMonitoring
Slow ControlsOnline Databases
Online/Offline/MC software
1
TriggerFMS (and FPD and FPDSMD) are all connected to QT boards and
DSM Tree• Full FMS/FPD trigger algorism document is available
http://www.star.bnl.gov/public/trg/TSL/Software/fms_algorithm_2009.pdf– 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 integratedImprovements (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 StatusFew 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) http://drupal.star.bnl.gov/STAR/blog/leun/2009/may/09/fms-trigger-analysis
• Steve’s analysis (off HPSS) http://drupal.star.bnl.gov/STAR/blog/heppel
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 runningBottleneck 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 diskspaceMinimal 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 resetZener 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
LeCroy1440
LeCroy1440
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 http://aquila.lbl.gov/FMS/electronics/FMS_HV_control.pdf
HV cable maphttp://les.will.post.the.page.gov
[email protected]:~/trg/???
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 GSTARSumming, mappingInverse-Calibration, Digitization & Calibration
9
• We’ll have 1st 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
Experiment GSTAR (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 StatusTrigger 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 AnalysisMuDST is produced ~months laterUsed for FMS-TPC or FMS-BEMC correlation analysis
12
Online and Offline Analysis code StatusBNL & 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 reconstructionCode is available : rcas://hank/put/the/file.tar
- PSU package = c++/root wrapped+ Code cleanup/re-organization+ New cluster finderCode 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
Experiment GSTAR (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
g2r
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
g2r
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 PlanFTE month Pros Cons
Plan1 0 No work…
Not integrated…
Plan2 6??? Fully Integrated…
A lot of workFilesize…
Plan3 2??? Less workMaintain “current” pathA step towards plan2…
…
20