Read VELO hit efficiencies in the digitisation

This MR includes the changes needed in the VPDigitCreator to remove hits according to an efficiency map in SIMCOND. The efficiency map is only included in simcond for now, with dd4hep for later this year.

Right now still a draft, running tests.

Initially associated with: lhcb-conddb/SIMCOND!241

2025-01-09) it should initially go with lhcb-conddb/SIMCOND!268 (merged) that has perfect conditions

@hcroft @tlatham

added Simulation label

added 1 commit

• 82d38261 - Remove old optional, rename gaudi option

Compare with previous version

added 1 commit

• 54cbbdae - Properly use thresholds only if condition exists

Compare with previous version

There is one open thing that I want to fix: I'm still looking for a nice way to access the entire condition catalogue, such that I can access the conditions per sensor.

In the VPDepositCreator this is done with a get<Condition>, which is rather old-school: https://gitlab.cern.ch/lhcb/Boole/-/blob/master/VP/VPDigitisation/src/VPDepositCreator.cpp?ref_type=heads#L228 Is there a nicer way to do this, @bcouturi ?

UPDATE: I have changed the structure in SimCond to be one condition, with multiple paramVectors (like the readout information of the UT).

added 1 commit

• ace3e3ae - Change conditions to paramvectors

Compare with previous version

added 1 commit

• 9c3002a3 - Fix binning bug (thanks Mark)

Compare with previous version

mentioned in merge request lhcb-conddb/SIMCOND!237 (closed)

Any feedback from your side @tlatham @hcroft ? If not I'll continue with the '24 maps and un-draft this.

It looked OK from what I read, I have not tried the code though. If you can replicate the efficiency maps you expect then it should be working. It would be worth just checking the memory footprint of this, you have a 32 bit precision float for each 16x16 block which gives an array of about 5Mb in size (if I've done the maths right). I'd check if using say an 8 bits integer as a fraction of 1.0 which, which gives a resolution of 0.3% efficiency per increment works and would be 4 times smaller in memory. This would reduce the rate of CPU cache misses significantly and can have a significant speed implication.

So

#include <cstdint>
...
// Store efficiency as 0->255 per 16x16 pixel sensor patch
using HitEfficiencies = std::array<std::array<uint8_t, nEfficienciesPerSensor>, VP::NSensors>;
...
return all_efficiencies[sensorNumber][sequential_bin_id]/255.0; // scale to fraction
...
              det.runOnAllSensors( [&]( const DeVPSensor& sensor ) {
                // just fill with 1.0 = 255, as the efficiencies are not yet in dd4hep
                hitEfficiencies[to_unsigned( sensor.sensorNumber() )].fill( 255 );
              } );
...
auto cond = efficiencyCond[conditionName].as<std::vector<double>>();
std::transform( cond.begin(), cond.end(), hitEfficiencies[to_unsigned( sensor.sensorNumber() )].begin(),
                    [](const float &cond){ return static_cast<const uint8_t>(cond*255.);}
    ); 
...

Note the code above is untested, so may not work yet.

Actually use (cond+(1/510))*255 as otherwise it will round the efficiency downwards, sorry still thinking about the implementation.

added VP label

OK, ran a test with the 2024 data with the algorithms provided by @mwaterla - this looks good. I'll push the '24 efficiency ratios to the simcond branch.

mentioned in merge request lhcb-conddb/SIMCOND!241

changed the description

/ci-test --model lhcb-sim11 !559 (closed)

added ci-test-triggered label

changed milestone to %Digi17b/2025.03

• [2024-06-18 12:31] Validation started with lhcb-sim11-mr#22