Persistency Service in CMS Short

1
Persistency Service in CMSShort Medium Term
Evolution

• Vincenzo Innocente

2
Status at 31/10/2002

• Objy based COBRA on a cvs branch
• In future only bug correction
• Root based COBRA on the cvs Head
• First pre-release available
• Still under test
• Works only to/from the sandbox (local directory)
• Covers basic production and analysis use-cases
• Only Linux 6.2 gcc2.95.2
• cint generated code is compiler (platform?)
  dependent

3
Xmas Release

• Root pre-release fixing few bugs we found
• Full production use-case coverage
• Access to remote file on the LAN
• rfio or rootd
• integration of a xml file-catalog
• Test of MySQL file-catalog
• ref-count memory management
• Support for dynamic loading of data-product
  libraries
• RH 7.3 gcc 3.2.
• Solaris with stlport?

4
COBRA-Root
CMS optimized layer
Objy Binding
Persil
Root
5
Parallel Runs without Concurrency

• Purpose to run parallel long jobs without
  conflict
• Solution
• First, one short run writes out run independent
  metadata (a few minutes). No parallelism needed.
• Then, many parallel event runs write into
  uniquely identified files. The metadata is
  accessed read-only. These are the long runs
  handling event data.
• An event run can then be attached to the metadata
  by a separate job taking only seconds.

6
Winter Mode

• Owner/DataSet configuration initialized once
• One to one correspondence between Owner,
  Event-product-types and application to run
• Initialize MetaData using the same application
  that populate runs (.orcarc card)
• Jobs run independently
• Each job writes in his own set of files
• Single-Run metadata in EVD-Collections file
• OutputRunNumber is user defined (.orcarc card)
• Attach run at the end of the job
• Use CARFResume written in a special file

7
Transition to POOL

• Open issues
• Dictionary (schema)
• How to populate it (IDL, XML, .h)
• How to use it
• LCG-Dict vs CINT-Dict
• NEW agreement to produce a single product!
• Generated code location, dependencies
• Object Identifier (LongRef)
• Object Cache
• Fixed tree/folders structure
• Garbage collected
• Ref-counted
• Role of TRef

8
Experiment classes
External Classes (e.g. CLHEP)
.xml .idl .adl
Possible data flow
.h
.h
Data flow
rootcint
gccXML
C
Streamer
ROOT I/O
PYTHON
Python Dict
Streamer
Interpreter
CINT Dict
9
Pool Storage Hierarchy
Data Cache
StorageMgr

• Object Pointer
• Persistent Address

DiskStorage
10
Pool off the Grid
Collections
MySQL or RootIO Collection
User Application
File Catalog
XML / MySQL Catalog
RootI/O
Meta Data
MySQL
LCG POOL
Disconnected Laptop
11
Pool on the Grid
Collections
Grid Dataset Registry
User Application
File Catalog
Replica Location Service
Grid Resources
Replica Manager
RootI/O
Meta Data
Meta Data Catalog
LCG POOL
Grid Middleware
12
Outlook short term

• COBRA 6 on RH 6.2
• Support of current analysis
• Access to old data
• Reference for regression tests
• COBRA 7
• Test Root in production environment
• Try User analysis strategies
• OSCAR validation
• Prepare DC04 pre-production
• Migrate to RH 7.3 and gcc 3.2

13
Outlook medium term

• Pool
• Expect convergence on stable API soon
• Still in a state that a 2 hour meeting changes
  strategic decision
• MetaData management and file access requires
  collaboration with Grid projects
• Users will interface to the cache manager
• It may remain experiment (application) specific
• First public release foreseen before Xmas 02
• CMS will start a pilot project as early user
• Time of migration of COBRA to Pool will depend on
• the evolution of the new dictionary strategy
• the integration of Grid middleware