# Presentation: 394218

## QM02 production and mDST

- Straw-man QM02 production plan (to set scale)
- time limitations
- physics motivations
- storage requirements
- storage realities (summary)
- Common mDST
- looser & fatter than previously anticipated
- Iterate on straw-man QM02 production plan
- related issues: ordering of processing

- ma lisa - STAR collab mtg feb2002

## Straw-man QM02 production plan

- (Assuming no new calibrations show-stoppers) plan to
- migrate NEW  PRO and begin QM02 production ~18 Feb
- 	( just 19 weeks for production until end of 1 July)
- 	hope/desire homogeneous production (consistent reco software) for full production
- Use Jerome’s numbers for production rate (real time)...
- Au200Au central		0.38 Mevts/wk
- Au200Au minbias	1.4  Mevts/wk (*)
- pp minbias		4.2  Mevts/wk (**)
- ... and stats requirements for desired physics to estimate overall time
- machine duty factor 60%
- (*) x 0.7 if MinBiasVertex instead of ProductionMinBias
- (**) assumes 60% usable events

- ma lisa - STAR collab mtg feb2002

## Straw-man QM02 production plan - desired stats

- Au200Au central fullfield	3.0 Mevts	7.9 wk
-  yield & crude spectrum
- high pT spectrum to ~10 GeV
- -bar
- K0 -K0 HBT
- Au200Au minbias fullfield	3.0 Mevts	2.2 wk
- v2  of K0, 
- high pT v2
- Au200Au central halffield	0.25 Mevts	0.65 wk
- HBT: R(pT), K- correlations
- low pT spectra
- Au200Au minbias halffield	0.55 Mevts	0.55 wk
- HBT: R(pT,)
- pp triggers (incl hightower)	?10.0 Mevts?	2.3 wk
- spin analyses
- high pT reference
- K- correlations

- 13.6 wk ~ mid-late May

- workable _if no major hiccups_

- ma lisa - STAR collab mtg feb2002

## Storage requirements of QM02 production (ONE pass/version)can we continue with “business as usual?” I

- STAR DSTs (event.root files / no hits):
- AuAu central:	(3.0 + 0.25)Mevt x 1.8 MB/evt	= 5.9 TB
- AuAu minbias:	(3.0 + 0.55)Mevt x 0.57 MB/evt	= 2.0 TB
- pp		10 Mevt x 0.1 MB/evt		= 1.0 TB
- ~ 9 TB required *can* fit into the ~11 TB we should consider for QM02 prod

- So, yes, so far we could continue as usual, although capability for keeping multiple (e.g. pre- and post-QM02) or test productions available on disk would be severely restricted
- But what about the files that most PWGs usually actually use for analysis... ?

- ma lisa - STAR collab mtg feb2002

## Storage requirements of QM02 production (ONE pass/version)can we continue with “business as usual?” II

- Storage requirements of QM02 production (ONE pass/version)can we continue with “business as usual?” II

- The “big four” PWGs (EbyE, Strangness, Spectra, HBT) do not analyze directly STAR DSTs (primarily for speed reasons), using instead ntuple/tree-based DSTs with similar event/track cuts

- HBT DST ~ 23 x smaller than STAR DST (event.root files w/no hits)
-  require 9TB/23 ~ 400 GB for single QM02 production
-  “big four” could *almost* keep their QM02 DSTs on 2x800 GB PWG disks
- 	(but would need some more, to keep 130 GeV data as well)

- But again, let’s say yes, barely, the big four could continue as usual

- ma lisa - STAR collab mtg feb2002

## But... should we continue this way?

- _Yes_
- it’s easier-- we are all set up and used to it (and don’t bother me when QM02 is on the horizon)

- _No_
- it’s a bit silly to write essentially the same information into several files
- even the big four’s DSTs will grow when FTPC information is included
- the big four have new friends who might like some storage space too
- TOFp, RICH, high-pT (??) Spin, EMC all have their own DSTs now
- fragmenting the data (tracks in one ntuple, EMC in another, V0s elsewhere) is short-sighted and does not exploit full potential of STAR
- e.g. v2(V0) analysis could not use flow pDST and resorted to (slow) DSTs (well, could have used HBT DST...)
- IMHO: even if we get away with it this time, at some point in (near) future, we will have to come to same solution to which every mature analysis/experiment comes-- we should start and get experience with this
- common datasource encourages common cut values (centrality...)

- ma lisa - STAR collab mtg feb2002

## But... are we ready for a common DST?(common = all detectors in + all groups could use)

- Well, yes, as long as we are not too dogmatic...

- Big Four: settled on contents & quality cuts for TPC info  ~ high compression

- newer systems still developing cuts/analyses  would prefer less compression
- EMC
- depending on analysis (pp or AA), need hits, clusters, tower sums
- keeping all (redundant info) means data *expansion* ~x2 relative raw data
- ~15KB/evt central AuAu  (raw data ~8KB/evt)
- on-the-fly expansion ~ 1 sec/evt
- RICH and TOFp
- compression could be quite high eventually, but for now...
- each would desire ~ 1KB/evt (central AuAu)
- FPD
- ?tiny? ?include?
- FTPC
- assume similar information volume/track as main TPC

- ma lisa - STAR collab mtg feb2002

## A possible “common” DST

- Sum of:					kB/evt (central AuAu)
- present HBT DST (tracks, V0s kinks...)	  80
- EMC expanded info			  15  (when present!)
- TOFp					    1
- RICH					    1
- FTPC “pessimistic” (?)			100
- Total				            ~200

- This still represents a compression x 1/9 relative to STAR DST, (and it would be faster)
- This would reside on production space (11 TB) not PWG space (DSTs not disk-resident)
-  space for multiple versions (think ahead...)

- ma lisa - STAR collab mtg feb2002

## Specific proposal

- Adopt common DST, including “fat” data from new subsystems
- implementation “volunteers”: Frank & Mike
- In production, create
- event.root files, “all” of which migrate quickly to HPSS
- common DST, which remain disk-resident in production area (freeing space on PWG disks)
- in principle could *also* create special DSTs for RICH, TOFp, EMC
- ~10% “extra charge”
- subsystems should act “responsibly” towards common DST (migrate improvements)
- common DST must be re-generable from event.root files
- proper Maker taking StEvent as input
- can fix small calib etc. issues without full reproduction

- ma lisa - STAR collab mtg feb2002

## Summary of I

- Straw-man QM02 sets scale for...
- time requirements
- we can meet straw-man physics goals with *some* safety, but we must be serious about readiness/homogeneity
- storage requirements
- we *could* continue as usual, but would probably regret it - see previous reasons
- STAR-wide common DST proposed
- HBT-DST + “fat” data from new systems
- speed, storage, commonality benefits
- volunteers for implementation *if* folks are on-board

- ma lisa - STAR collab mtg feb2002

## Strawman QM02 productionplan - iteration

- Au200Au central fullfield	3.0 Mevts	7.9 wk
-  yield & crude spectrum
- high pT spectrum to ~10 GeV
- -bar
- K0 -K0 HBT
- Au200Au minbias fullfield	3.0 Mevts	2.2 wk
- v2  of K0, 
- high pT v2
- Au200Au central halffield	0.25 Mevts	0.65 wk
- HBT: R(pT), K- correlations
- low pT spectra
- Au200Au minbias halffield	0.55 Mevts	0.55 wk
- HBT: R(pT,)
- pp triggers (incl hightower)	?10.0 Mevts?	2.3 wk
- spin analyses
- high pT reference
- K- correlations

- comments?

- ma lisa - STAR collab mtg feb2002

## Ordering of data processed... some issues

- In general, process data from end of run backwards
- Jerome willing to run 2 datasets (e.g. AuAu-central, pp) parallel
- Hold off on post-13 Nov due to calibration issues?
- high pT, spin groups want large-statistics end-of-run pp “early”
- SVT group wants this dataset run “late”
-  tentative compromise target-date: 15 March
- FTPC - expected reco upgrades ready mid-March
- - need short test-production and then likely reproduction ~ 80Kevts
- - “little” things like this should not perturb us too much, but we should try hard to maintain homogeneity of QM02 production

- ma lisa - STAR collab mtg feb2002