Persistence Technology and I/O Framework Evolution Planning

1. Persistence Technology and I/O Framework Evolution Planning David Malon malon@anl.gov Argonne National Laboratory 18 July 2011

2. Introduction • ATLAS has been informally reviewing its I/O and persistence architecture • And design and implementation and deployment and performance and … • Motivated by many factors: • Improving performance across a variety of storage and access platforms, data products, and use cases • Support for increasingly-many-core architectures • Refactoring to make implementations cleaner, more consistent, and more maintainable • Feature wish lists that did not make it into production before current LHC running • … • But also by longer-term planning, particularly in the context of the computing side of ATLAS upgrade planning • One part of this process is reconsideration of our strategy regarding persistence technologies and interfaces thereto • POOL is an essential element of that strategy today David Malon

3. ATLAS and POOL • Several issues related to the future of POOL and of common persistence strategies were discussed at a joint meeting with LHCb and IT representatives last December • LHCb has since “officially” decided to drop POOL, as was discussed at that meeting • More important, therefore, that we decide upon a strategy with respect to POOL in particular • Spectrum of options • ranging from simply incorporating those parts of POOL that we care about into the ATLAS code base … • through taking a serious look at developments in LHCb/Gaudi persistence that we are not using … • to availing ourselves of the opportunity to address known architectural shortcomings and to do something more ambitious • Doing nothing is probably not a long-term option • And probably not a good idea anyway David Malon

4. Evolutionary, or revolutionary, or ? • Should we begin by moving POOL code into the ATLAS code base, and building it from there rather than externally? • What does this mean, and what is required to accomplish this? • In packaging/repackaging, in time, in effort, … • There are alternatives: e.g., we could instead aim to re-implement the portions of POOL that we care about, and not move any POOL code directly at all… • Or use Gaudi/LHCb equivalents, if available, or … • Should we do this as a prudent evolutionary strategy even if our eventual strategy is more ambitious? • And backward compatibility, or at least the ability to read old data, is essential • What about more direct use of ROOT? • And remember technology independence? David Malon

5. ATLAS and LHCb/Gaudi persistence capabilities • At last December’s meeting, we talked about what we are and are not using from POOL • And what LHCb is and is not using • Peter will say more about our use of POOL • My impressions from last time: • While we need to examine more closely what LHCb is doing, and while we will definitely learn from this, I am not optimistic that we will directly reuse much of that code • Probably no shared conversion services, for example • Certain proposed extensions to I/O framework and persistence technology will likely be ATLAS initiatives, not common projects • But this could change in the context of control framework initiatives to support multicore processing • And there will certainly be common interest in certain ROOT improvements and potential optimizations • Meeting on Thursday with ROOT developers and some CMS people David Malon

6. This week • POOL plan in particular • Strategy regarding missing features • Example: What would we do differently to support AthenaMP? • Time frame David Malon

7. Observations and impressions (which may be mistaken) • Advantages and disadvantages to moving POOL code into ATLAS code base • Not much IT effort put into POOL, but do we lose this source of effort entirely if we incorporate the code into ATLAS software? • Yes, but probably we should do it anyway • Advice/consulting from code authors (Markus Frank, LHCb) might still be extremely helpful for awhile • No experiment seems yet to have an I/O and persistence architecture that extends much beyond the conversion service layer • ATLAS may be the only experiment thinking much about this (Is this overstatement close to true? Maybe not now that people are thinking about components and services in support of multicore processing) • No other experiment seems to be thinking much about other persistence technologies • At least for event data David Malon

8. An architecture for I/O and persistence • Independence of persistence technology is important—increasingly so as we explore alternative storage technologies • Gaudi/Athena architecture doesn’t care whether we are writing to a file or a database or a UNIX pipe or … , but in practice this means that … • Current architecture (outstream, persistence service, conversion service) essentially ends at the conversion service: no real architecture beyond this • ATLAS adds explicit persistent state representation • Some implications, even today: • Resource sharing, concurrency control, multi-stream transaction contexts are not addressed or addressable in the current architecture • Affects even objectives as conceptually “simple” as writing TAGs and AOD into the same file • Today, technology control, communication, and optimization are handled by methods to pass opaque “hints” to the underlying technology • This is not an architecture • Similar implications for input • Exploitation of emerging computing and storage platforms will require an explicit architecture for I/O and persistence control David Malon ATLAS Upgrade Week, Oxford, UK

9. Possible steps in a work plan? • Move POOL code into ATLAS code base; build as part of ATLAS builds, rather than from LHCCMT releases • Primum non nocere • Ensure that we can write/read using ATLAS code that may really just be POOL repackaged • Rename as necessary • This would be the foundation for further evolutionary work • What needs to be added to address unmet requirements? • What can be dropped? (Unused, unneeded features? Unnecessary layers?) • In parallel, take a closer look at Gaudi/LHCb persistence • What if anything can we use out of the box, versus what can we learn from, but not use directly? • In parallel: assemble our functional upgrade requirements • For shared context, for support of I/O from parallel workers in AthenaMP, etc. • Assess both what is necessary and what is feasible in the appropriate time frame (Phase 0 shutdown for some functionality, earlier(?) for some multicore extensions? If we agree, can we put a timeline (and names!) on some of these steps? David Malon