1. WP12 - General Development News Sandro Wenzel

2. Software quality / development workflow
ROOT macros
ROOT macros and compiled libraries go quickly out of sync and could cause defect code
Did a campaign to systematically look if macros in O2 still execute fine with ROOT
Fixed many macros which did not run (see
Few macros could not be fixed and were renamed to “.C_backup”; (please check if they are still needed)
from now on the pull request checker will automatically check all our macros and flag error when there is a problem
Makes keeping a good code state a lot easier

3. Arbitrary Types with FairRoot/IO
Status quo
So far, only classes of type TNamed or TCollections could be exchanged with the FairRootManager for persistent IO and exchange of data between tasks
Registering outgoing data
TClonesArray *mHits;
mHits = new TClonesArray("tpc::Hit");
iomgr->Register("TPCHit", mHits, true);
mHits = dynamic_cast<TClonesArray*>(iomgr->GetObject("TPCHit"));
Asking for incoming data
Memory overhead due to
Data elements needs to be TObject (~16bytes overhead)
Data elements are stored as pointers (8bytes overhead)
Type unsafe code
TClonesArray can’t do type checking at compile time

4. Arbitrary Types with FairRoot/IO
New feature
A pull request has been made to FairRoot which extends the FairRootManager to handle branches of any type for the purpose of IO and data exchange
Store hits in stl containers
Registering typed outgoing data
std::vector<tpc::Hit> *mHits;
iomgr->RegisterAs("TPCHit", mHits, true);
mHits = iomgr->InitObjectAs<std::vector<tpc::Hit>*>("TPCHit");
Asking for typed incoming data
No negative effect on split level of persistent branches
Feedback/comments on PR welcome
Once PR accepted, I would like to move completely away from TClonesArrays in favour of std::vectors

5. Lazy loading of branches with FairRoot analysis runs
Simulation writes hits for all detectors into same tree (different branches)
Can lead to very large trees/files quickly
Example: 4 PbPb hijing events with ~15000 primaries each lead to ~1.7GB on disc
When processing these hits (digitization) the standard FairRunAna class will load every single branch for a given event into memory
Causes large memory buffers to be allocated (~3GB for above example)
Might be substantial overhead in cases where we do not consume all these data, for example:
Digitize only ITS hits
Digitize only one TPC sector

6. Lazy loading of branches with FairRoot analysis runs
Proposing an addition to FairRootManager (PR636) that allows to keep track of which processing task needs which data + made a prototype modification to FairRunAna (O2RunAna)
Now able to load only branches actually needed for processing; May lead to large gain in memory and CPU time:
tpc-run-sim -m digi -n 4 —-dSector 2 # digitize only sector 2
MaxMemory: MB
CPU time 21.08s
MaxMemory: MB
CPU time 7.66s
Definitely useful for rapid prototypic, profiling algorithms
A step in organizing data and processing in direction of efficient parallel device-based processing

7. MC labels Discussed some time ago the issue of MC-labels
TPC has restructured their digitization to make use of external MC labels
Allows to have arbitrarily many labels per data element
Labels are stored in a separate branch and no more distinction between DigitMC and DigitRaw
Will report in one of the next meetings…
For now interested developers could take a look here:
PR #578: Shows how the final label branch is filled
PR #586: Generalization allowing to fill labels in random data order
Feedback welcome!