Added pixel smearing in VP to match 2023 data taking values

requested review from @gcorti

assigned to @tlatham

marked this merge request as ready

@gcorti @tlatham As discussed in the simulation meeting yesterday, I've adapted the code to run on SIMCOND. Note this has the same issues with the master branch with USE_DD4HEP ON, this works with USE_DD4HEP OFF only (the other stack of three MRs does the USE_DD4HEP ON version). There is a warning about a C++20 only change, as that was updated by Sebastian Ponse and I did not want to undo it. I remade some of the plots from the talk listed above and they were as it was (i.e. the changes are implemented OK). As far as I know this MR is not dependent on any other changes, except setting option(USE_DD4HEP "Controls whether DD4hep is used for the subdetectors supporting it" OFF) in LHCb/cmake/LHCbOptions.cmake.

changed the description

requested review from @tlatham and removed review request for @gcorti

assigned to @gcorti and unassigned @tlatham

Hi David, thanks for preparing this, however I don't see very much difference wrt !456 (closed). If I rebase !456 (closed) on master and do a git diff wrt this I see the following differences:

The C++20 fix in the DetDesc code in VPDepositCreator.cpp is here but not in !456 (closed)
Changes of hard-coded 208 into VP::NSensors in both VPDepositMonitor.cpp and VPDigitCreator.cpp are in !456 (closed) but not here
The locations of the threshold conditions in VPDigitCreator.cpp are Gaudi properties in !456 (closed) but are hard-coded here
In !456 (closed) in VPDigitCreator.cpp there is a check that the threshold condition is defined when in DD4hep mode, and if it is not defined an array full of 1000. is returned instead (although I think there is a small bug in that code - see !456 (comment 7868643)). There is no such check here.

How should we proceed?

@tlatham I can copy these changes across, I started from master and was trying to make the changes as small as possible to minimise the changes for mistakes. It is easy enough to port them across but none will change the output. I expect to be able to do that today.