NA49 Data Model

1. NA49 Data Model Predrag Buncic

2. Analysis “SHELL” • NA49 software environment for development and production • https://edms.cern.ch/file/812336/1/software_proposal.txt • Basic principles • The SHELL has to be simple • The SHELL should not restrict the capabilities of any major language • The SHELL should allow multiprocessing (multiprocesses and multiprocessors)

3. DSPACK • We had two implementations of SHELL • DSPACK came out as winner • Faster and more memory efficient than NASE • Basic features • Shared memory based Data Manager • Data is stored as arrays of C like data structures • Supports pointers and nested structures • Client/Server system • Extensible I/O system • API for C/C++/F77 • Command line tools

4. Memory Manager Definitions #0 Constants #2 Event data #1 • Inspired by ZEBRA • Manages contiguous memory banks (sections) • Shared memory • Access by pointer • Simple API but no protection • Sections • #0 Definitions, derived from header files • #2 Constants, persist during lifetime of the server • #1 Event data, cleared before next event is read

5. DSPACK Repository typedef struct vertex_t DS_TEMPLATE { /* NA49 c.s. */ int_t iflag; /* vertex flag */ int_t id_det; /* Detector id */ int_t id_vtx; /* vertex type */ int_t n_trk_fit; /* Number of tracks used for fit */ int_t n_trk_out; /* number of outgoing tracks */ float_t x; /* coordinates of vertex */ float_t y; /* y */ float_t z; /* z */ float_t sig_x; /* error of x */ float_t sig_y; /* error of y */ float_t sig_z; /* error of z */ float_t pchi2; /* P(chi^2,ndf) of vertex fit */ struct track_t *daughter_p; /* ptr to first daughter trk */ struct track_t *mother_p; /* ptr to mother trk */ void *covar_p; /* ptr to error matrix of vertex */ void *avertex_p; /* ptr to auxillary vertex struct */ struct kfit_t *kfit_p; /* ptr to kinematic fit struct */ struct vertex_t *next_p; /* ptr to next detector vertex */ } vertex_t; • DSPACK searches directories in $DSPACK_REP_PATH looking for header files and defines data structures • This information is then stored in every file • DSPACK files are self contained and self describing • One can always read file header and DSPACK will recreate corresponding include files • Inline comments are preserved

6. Support for C,C++,F77 structure /vertex_t/ integer iflag integer id_det integer id_vtx integer n_trk_fit integer n_trk_out real x real y real z real sig_x real sig_y real sig_z real pchi2 integer daughter_p integer mother_p integer covar_p integer avertex_p integer kfit_p integer next_p end structure • vertex_t structure in f77 representation

7. DSPACK Files Definitions #0 Constants #2 Event data #1 Event data #1 Definitions #0 • File format • Sequential, same layout as in memory • Pointers are supported converted to indices on write • One has to always read complete event section • This is done in one read operation • Features • Automatic handling of file lists, directories • Remote, federated and differential files • Support for plugins

8. DSPACK Plugins • Way to extend file and data handling capabilities • Can be invoked to ‘activate’ object (definition is present but there is no data) • This triggers database access (HEPDB plugin) • Filters that are inserted in input or output stream • Can do all sort of file conversions • Can even run second event loop (embedding) • Examples in the library [lxplus249] /afs/cern.ch/na49/library/pro/SCRIPTS/src $ ls *.plugin bos.plugin embed.plugin hepdb.plugin rfio.plugin update.plugin buffer.plugin fmsh.plugin mini.plugin rfiow.plugin zbuffer.plugin calibrate.plugin fmshw.plugin mtric.plugin script.plugin dedx.plugin gunzip.plugin mtsim.plugin tric.plugin xrootd.plugin

9. Conclusions • DSPACK served NA49 well for many years • Possibly too many… • ROOT I/O and C++ seem to be the norm today and for years to come • Some features will be missed • Shared memory client/server • Capability to stream events • Plugins and filters that can seamlesly extend I/O capabilities