Make detection of geo setups to check more granular + bump geo hash

• Improve the geometry setups testing so that only modified ones are checked in CI (still possible to trigger full check by hand, no change for Nightly/Weekly)
• Bump geo hash (catch-up to master there)
  • Downgrade lmvm much from v23a to v20c in lmvm setup
  • Correct trd v23 info
  • Inactivate detector systems in two mcbm setups to fix/hide crashes (CbmSoft/cbmroot_geometry!250 (merged), to be merged => draft)

Added 02/02/2024:

• Make the CI test on mcbm sim pulls more robust + related fixes

Changed 07/02/2024:

• Script executed within CMAKE chain instead of by Gitlab before cmake called, as need geo repo initialized
  => No variable exported to Dart.cfg anymore
  => Some of the screen printout would be lost as "eaten" by CMAKE, therefore redirected to 2 log files geo_check_*_upstream_repo.log in the build folder, could be useful if git errors
• Related changes

Redmine: Refs #3135 #2646

Draft state will be removed once CbmSoft/cbmroot_geometry!250 (merged) is merged

Changed 15/02/2024:

• Hash bump introduces now only the detectors inactivation as the two other changes were introduced separately

requested review from @f.uhlig

assigned to @e.clerkin

requested review from @e.clerkin and removed review request for @f.uhlig

assigned to @f.uhlig and unassigned @e.clerkin

approved this merge request

Looks okay. Let's see if it works.

I should add that I tested locally the following cases:

• No change to Cmake file
• Change to Cmake file but no change to hashes
• Change to Cmake file and hashes but no change to setup files between hashes
• Change to Cmake file and hashes and change to a single setup file between hashes

The last following case will be tested once we introduced the hash bump for the remaining geo MR:

• Change to Cmake file and hashes and change to multiple setup files between hashes

added 2 commits

• bdbc058c - 1 commit from branch computing:master
• 0377767f - Make detection of geo setups to check more granular: only modified ones checked

Compare with previous version

added 2 commits

• 9909e833 - Make detection of geo setups to check more granular: only modified ones checked
• 037747c5 - [externals] Bump geo hash (catch-up to master there)

Compare with previous version

marked this merge request as ready

Waiting for first pipeline to finish before starting the rebased one to avoid potential Gitlab status conflict

Dear @f.uhlig, @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

added 3 commits

• bdbc058c - 1 commit from branch computing:master
• 8b1e9f50 - Make detection of geo setups to check more granular: only modified ones checked
• 65eda39b - [externals] Bump geo hash (catch-up to master there)

Compare with previous version

changed milestone to %OCT23

I can reproduce the failed test locally with debian12 on mcbmop01 for both the "cmake style compilation" and the "Dart style compilation".

Will now try to have a look at the output files and code check

added 6 commits

• 8b54c71b - 1 commit from branch computing:master
• 7f3295d5 - Make detection of geo setups to check more granular: only modified ones checked
• b6338d35 - [externals] Bump geo hash (catch-up to master there)
• cb7fbb80 - L1 QA: fix TFile::Append overwritten object error
• 82755541 - QA core: make errors from CbmQaTask::CheckRange clearer for non-experts
• c93d7724 - mCBM SIM QA: Increase accepted range for TRD pulls mean to pass low stats CI

Compare with previous version

changed the description

@f.uhlig I managed to understand the problem I think:

• The mean of the time pulls in mTRD have a tendency not to be centered on 0
• The error message was confusing because the 3.5 sigma factor was not explicitly written
• The fact that we run with only 10 events for the mCBM sim CI did not help as then we are on the edge for statistics (80-100 entries in the plot) but increasing this does not help for the following reasons
  • Runtime is ok even at 100 events as mcbm as few hits (~factor 2 in time but all tests originally under 15s)
  • but a crash happens in HadronAnalysis when running with more than 50 events
  • and the increased statistics shrinks the width but barely change the mean, so the QA CI test has an even higher chance of failing

=> the trick was to keep the same number of events but broaden the limit from the macro (ok I think/hope because affecting only mCBM)
=> eventually we may have to tune the pulls limit for MUCH in a similar way when new mcbm setups come

@s.zharko let me know if it is ok to have the last 3 commits in this MR.
I you prefer I can also make a separate MR with them, but then part of the reason for them may get harder to understand