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

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

Logging in to vae24.hpc
Compiling and installing your branch somewhere in /temp
Temporarily moving the source and build folders to new names
Sourcing <install>/bin/CbmRootConfig.sh

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

requested changes

added 1 commit

9fb0a4d2 - new source class for reconstructed timeslice output

Compare with previous version

resolved all threads

added 1 commit

96f3f4b5 - new source class for reconstructed timeslice output

Compare with previous version

@p.-a.loizeau If the latest changes of Sergei's are ok with you, please approve the MR.

added 4 commits

96f3f4b5...f5d367a4 - 3 commits from branch computing:master
89d6e013 - new source class for reconstructed timeslice output

Compare with previous version

approved this merge request

merged

@s.zharko,

cc @p.-a.loizeau, @v.friese, @se.gorbunov

your changes break on arm64 which took me some time to understand. When building the core directory on my macosx I get the following errors:

[  0%] Built target G__CbmData
[  0%] Built target flesnet
[  3%] Built target xpu
[ 18%] Built target CbmData
[ 21%] Built target G__CbmField
[ 25%] Built target CbmField
[ 25%] Built target G__CbmBase
[ 28%] Built target CbmBase
[ 28%] Built target CbmFlibFlesTools
[ 28%] Generating G__KfCoreOffline.cxx, ../../../lib/libKfCoreOffline_rdict.pcm, ../../../lib/libKfCoreOffline.rootmap
Warning: FindScope got an invalid tag decl
ERROR: FindScope about to return an invalid decl
...
Warning: FindScope got an invalid tag decl
ERROR: FindScope about to return an invalid decl
gmake[2]: *** [algo/kf/core/CMakeFiles/G__KfCoreOffline.dir/build.make:79: algo/kf/core/G__KfCoreOffline.cxx] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:7429: algo/kf/core/CMakeFiles/G__KfCoreOffline.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

The first thing which is broken and probably was already before is that the core directory has a dependency on the algo directory. The core directory should depend only on externals (and itself) but definitely not on sim, reco, algo, MQ, analysis, etc. This is my opinion a circular dependency. This should be fixed immediatly

The real problem why it crashes in my case is the the LinkeDef file of KfCoreOffline which contains the following lines

#pragma link C++ class cbm::algo::kf::TrackParamBase<Vc_1::Vector<float, Vc_1::VectorAbi::Sse> > + ;
#pragma link C++ class cbm::algo::kf::TrackParam<Vc_1::Vector<float, Vc_1::VectorAbi::Sse> > + ;

Since SSE isn't known in case of ARM64 this needs to be changed, at least a guard in case of ARM64 is needed.

EDIT PAL: added formatted code tags

The first thing which is broken and probably was already before is that the core directory has a dependency on the algo directory. The core directory should depend only on externals (and itself) but definitely not on sim, reco, algo, MQ, analysis, etc. This is my opinion a circular dependency. This should be fixed immediatly

I think this is a confusion due to the naming of the library: KfCoreOffline is fully contained in the algo folder (similarly for CaCoreOffline).
The online back linking I saw in the core folder (outside of the logger compatibility header AlgoFairloggerCompat.h in the digi classes) is the following, which concerns only the CbmQaBase library which is not used anywhere else in the core folder

core/qa/CMakeLists.txt:49:  AlgoOffline

Since SSE isn't known in case of ARM64 this needs to be changed, at least a guard in case of ARM64 is needed.

For this we indeed need to address it, I think I saw some SSE guards somewhere in core while I was trying to fix the header install problem, so there should be some examples around for @s.zharko there.

I don't care so much which of the libraries in core depends on something in algo, I only made the point that there is a dependency which should not exist. We put some afford into separating the code in the top level directories to avoid such dependencies and we should bring back that separation again.

The compilation issue is fixed with !2080 (merged).

The dependency problem needs still to be fixed.

From what I could see the only part of Algo which is used in the core qa side are the "non-root histograms"... so probably the solution would be to extract these and the YAML library and move them to another folder for "tools" libraries (as @s.zharko proposed last or previous to last week)

@p.-a.loizeau,

that would be the proper solution and I am fine with that. I am looking forward for the merge request

mentioned in merge request !2080 (merged)

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

Merge request reports

Activity