FairSource for the timeslice-based reconstruction output in the online binary

The class provides an implementation of FairSource (CbmSourceRecoTimeslice) to read the hits and tracks, which are stored during a timeslice reconstruction in the online binary. The class CbmTaskInspectRecoTimeslice is a demonstrator of accessing the corresponding vectors.

added Online Reconstruction labels

requested review from @p.-a.loizeau

assigned to @v.friese

added 1 commit

• 2896220f - new source class for reconstructed timeslice output

Compare with previous version

added 1 commit

• 1936e846 - new source class for reconstructed timeslice output

Compare with previous version

added 1 commit

• 8e6b5432 - new source class for reconstructed timeslice output

Compare with previous version

Dear @d.smith, @fweig, @se.gorbunov, @s.zharko, @f.uhlig, @v.friese, @p.-a.loizeau,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

@p.-a.loizeau Looks fine from my side. Are you able to have a look?

added 18 commits

• 8e6b5432...4613e86e - 17 commits from branch computing:master
• 2d32d066 - new source class for reconstructed timeslice output

Compare with previous version

@s.zharko There are some "missing libraries after installation" found by the new test under vae24:

Processing /tmp/custom-executor874274408/builds/computing/cbmroot/install/share/cbmroot/macro//loadlib.C("/tmp/custom-executor874274408/builds/computing/cbmroot/install/lib/libCbmRecoTasks.so", "CbmReco")...
In file included from libCbmRecoTasks dictionary payload:105:
/tmp/custom-executor874274408/builds/computing/cbmroot/install/include/CbmTaskInspectRecoTimeslice.h:12:10: fatal error: 'global/RecoResults.h' file not found
#include "global/RecoResults.h"

Processing /tmp/custom-executor874274408/builds/computing/cbmroot/install/share/cbmroot/macro//loadlib.C("/tmp/custom-executor874274408/builds/computing/cbmroot/install/lib/libCbmRecoSteer.so", "CbmRecoUnpack")...
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
   Missing FileEntry for KFParticle.h
   requested to autoload type KFParticle
In file included from libCbmRecoSteer dictionary payload:101:
/tmp/custom-executor874274408/builds/computing/cbmroot/install/include/CbmSourceRecoTimeslice.h:12:10: fatal error: 'global/RecoResultsInputArchive.h' file not found
#include "global/RecoResultsInputArchive.h"

=> From the error messages, it could be a simple re-occurence of the "partial path in include VS flat path in install" problem

Similarly to what I advised Daniel in the redmine issue about the HAL library, you should be able to test it locally by

1. Logging in to vae24.hpc
2. Compiling and installing your branch somewhere in /temp
3. Temporarily moving the source and build folders to new names
4. Sourcing <install>/bin/CbmRootConfig.sh
5. Opening root and entering the two following commands:

   gInterpreter->AutoParse("CbmReco")
   gInterpreter->AutoParse("CbmRecoUnpack")

I am not sure what is going wrong with the other 4 tests, so I tried to restart them (they should show the same printout bu had completely different errors, with stuff related to more basic origins like boost or the OS)
EDIT: confirmed to be the only errors after rerunning the other 4 "failing jobs", now they all give the same answer (sot sure what initially went wrong)

added 1 commit

• f0168b0d - new source class for reconstructed timeslice output

Compare with previous version

@s.zharko Jobs are not starting because all docker runners have all slots occupied by some CRI FW jobs. This should resolved itself in 45-60 mins from what I can see in the queue on the admin side (but it may take up to 1h30 if there are more queued jobs in other projects)

@f.uhlig Wondering a bit what we should do to avoid such cases in the future, as the current CRI project triggers something like 10 builds when a change is done to the base repo, so with 2 pipelines it can saturate all docker runners for 1h30-2h
Should we remove the xilinx-licence tag from at least of these runners?
or maybe just remove two slots from one of those and create a parallel runner on the same node with these slots and without the xilinx tag, similarly to how we handle the mCBM vs realData runners on run4?

added 1 commit

• 7055fad8 - new source class for reconstructed timeslice output

Compare with previous version

resolved all threads

approved this merge request

All good for me apart from the small comments and typos which should be added but do not need a review