Athena I/O Component Refactorization - Overview Random notes about todays agenda. Peter Van Gemmeren (Argonne National Laboratory (US))

Agenda AM 09:00 Local Welcome: Dr. Sebastien Binet 09:10 Workshop Welcome: Dr. David Malon 09:20 Athena I/O Component Refactorization - Overview: Peter Van Gemmeren 09:30 EventSelector: Paolo Calafiura –Common nucleus in Event Selectors 10:00 Discussion / Planning 10:30 Coffee 11:00 MetaDataSvc: Dr. David Malon 11:30 OutputStream: R D Schaffer –On Athena side, think a bit about how data, metadata, (and TAGs) can be written into a single file right now, multiple streams sharing a name, hoping they don't step on each other's toes –Single event data spread over multiple files (tracking and calorimentry, say, or ESD+ExtendedESD, or...) 12:30 Lunch

Agenda PM 14:00 ByteStream Components: Dr. Jack Cranshaw 14:30 Discussion / Planning 15:30 Coffee 16:00 Forum: I/O infrastructure outside Athena –Can we provide infrastructure that can be reused in part outside of Athena? in downstream non-Athena analysis, for example, but maybe even more broadly

EventSelector: Paolo Calafiura  What’s wrong with the current EventSelector: –Too many responsibilities: Iterate over collections, Throw collection incidents, Apply event selection, Read collection metadata, Iterate over files, Throw file incidents, Iterate over events, Seek events, Select events, (Provide addresses), Back navigation –Asymmetry with OutputStream No AthenaEventSelector base class –Dissimilarity between AthenaPOOL and other technologies (ByteStream) –Special treatment by Control framework Failure is really ‘no more events’

MetaDataSvc: Dr. David Malon  MetaDataSvc to handle in-file metadata was developed as an add-on component to the Athena POOL I/O infrastructure.  Should it become a base component similar to OutputStream or EventSelector (we don’t yet have the latter (yet)).  Writing is done via ‘shadow’ stream with same PFN. –Works but fragile  Merging metadata needs full athena frame work.

OutputStream: R D Schaffer  AthenaOutputStream uses a Tool to do most of the work.  Tool is technology specific and has a ConversionSvc (even though that could eliminate technology dependence). –We are using two different tools with AthenaPOOL AthenaOutputStreamTool depends on AthenaPoolCnvSvc, but not DataHeader. –Only used for PixelDCSTool (and PixelDCSTestWrite.py), TRT_StrawStatusSummarySvc, SCT_MonitorConditionsSvc, SCTCalibWriteSvc (and SCTCalib_topOptions.py) and LArG4GenShowerLib –Main difference is the use of DataHeader and infrastructure.

ByteStream Components: Dr. Jack Cranshaw  Was developed separately from AthenaPOOL infrastructure.  Some functionality had to be duplicated, because of missing common base classes: –E.g. Firing of FileIncidents  Some concepts are borrowed from AthenaPOOL: –E.g. DataHeader, Guid