STARCOMPUTING

STAR Computing Infrastructure

Torre WenausBNL

STAR Collaboration MeetingBNL

Jan 31, 1999

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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)

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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

Compact, for convenient disk storage and fast access, where ‘compact’ is to be defined by the tag users

Easily redefined and updated; notions of what should be in physics tags expected to change frequently

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

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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

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

Reconstruction tags: QA info to evaluate reconstruction performance, DST summary tags, PWG tags summarizing info uniquely relevant to PWGs and available at reconstruction time

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.

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

Tag ImplementationTags 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

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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.

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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.

Torre Wenaus, BNL

Collaboration meeting 31/1/99

STARCOMPUTING

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