1. STAR C OMPUTING STAR Computing Infrastructure Torre Wenaus BNL STAR Collaboration Meeting BNL Jan 31, 1999

2. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 Purpose Not an attempt at a comprehensive infrastructure overview -- infrastructure will be addressed 4-6pm tomorrow Addressing only a few issues of my choice! (Anticipating that this talk may be bumped off the Sunday agenda entirely)

3. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 Tag Database! Seems to be generating a lot of confusion and uncertainty! It really isn’t very complicated ---  ‘tag’ components of the event store are of the same nature as other components, with some different characteristics driven by the particular requirements for tags l Compact, for convenient disk storage and fast access, where ‘compact’ is to be defined by the tag users l Easily redefined and updated; notions of what should be in physics tags expected to change frequently l 100% disk resident (if in active use) with fast access performance and direct histogramming access at a premium  the ‘tag database’ is not a distinct entity from the event store; it is part of the STAR event store  the ‘tag database’ and the Grand Challenge query index are completely different entities; the latter is a subset of the former, and reads the former to build the query index

4. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 More on Tags  The event consists of many tag components, added to the event at different stages of processing, and coming from different parts of the analysis l Tags with online, DAQ, trigger information added to the event store when an event collection (run) and event are initially created in the online environment l Reconstruction tags: QA info to evaluate reconstruction performance, DST summary tags, PWG tags summarizing info uniquely relevant to PWGs and available at reconstruction time l Analysis tags: more refined PWG tags created at DST analysis time (a summary of the uDST, if useful)  Tag components should be highly granular, ie. don’t combine the needs of different groups in the same tag, to minimize interference when tags are redefined or updated. QA tags should be distinct tags.  Tag components are not, in general, histograms. They are typically C structs. Including histograms in some ROOT-based tags has been discussed.

5. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 Tag Implementation Tags in MDC1 were the tag-like components of the DST:  event_summary, dst_monitor_soft, dst_monitor_hard  not all filled, not all strictly tag info (database info; run conditions parameters)  In XDF files, stored together with all the rest of the DST (ie. Not as tags)  In the Objectivity event store, stored separately from the DST data itself, permanently on disk (ie. As real tags) For MDC2, priority is to define PWG tags built from the DST to use for GC query index definition, then usable for GC-based queries  Online/DAQ/trigger tags will be sorted out after MDC2  QA tags would be nice too! (QA info will be there in one form or another -- Maker-associated histograms) For MDC2, tags will be implemented both in Objy and in ROOT  redundantly; just to try both  Objy implementation essentially the same as MDC1  MDC2 ROOT event storage will support distinct disk-resident storage of tags

6. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 StEvent Implementation CVS version of StEvent includes  full class set as per Thomas’ design diagrams  table loader constructors to build StEvent for an event from MDC1 DST tables  an interim standalone makefile; integration into A reader, StRoot/StEventReaderMaker, is in CVS which  Reads DST events from MDC1 XDF files (working) or Objectivity (untested) and builds StEvent  Driver chain currently in ~wenaus/workdir/readEvent.C  Sample analysis maker StAnalysisMaker to access and use StEvent exists and will be filled out to be more illustrative this week Much thrashing against template problems in all of this, thanks to Sun  Customizations remain to go into official Makefiles This stuff is usable today on a ‘sit down with Thomas or Torre and set it up’ basis; should be end-user ready within a week.

7. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 ROOT News FNAL organizing a ROOT workshop for US users in March  STAR will be there  Address how needs of STAR, RHIC, Run II can be addressed in unified ROOT project; how our mods can be incorporated and how our design and prioritization input will be considered ROOT adopted as the analysis framework in ALICE  It is ‘in the door’ as a LHC experiment tool No change in CERN’s official position on ROOT; no support  Rumors of ‘change in ‘99’  Better, I suppose, than rumors of ‘no change in ‘99’, but can’t read into it more than that. We’ll see.

8. STAR C OMPUTING Torre Wenaus, BNL Collaboration meeting 31/1/99 Objectivity News Reading the Objy hypernews forum of BaBar is worrisome  Locking problems with multiple (11) concurrent writers in production; DB hangs  DB with concurrent production writers can hang when someone browses an unrelated part of the federation In talking to them last week, word is that problems are understood and being resolved, but, it gives one pause. BaBar’s Objy usage mode is much more aggressive than ours, making them much more susceptible to such problems, but the fact remains we have not tested concurrent usage performance of our usage mode yet at all While there is concern, as always, there doesn’t seem to be any backing away from Objy yet by BaBar, RD45 The schema evolution Objy supports seems to be fundamentally unusable by HENP: old executables cannot be run against an evolved schema DB  So it’s ‘roll your own’ class versioning