Skip to content

try to remove SPD/PRS and IIncidentListener from CaloFutureCorrections

Dmitry Golubkov requested to merge nospdprs-noincidents-calofuturecorrections into master
  1. removed SPD and PRS from CaloFuture[ESL]Correction ( see !1503 (closed) for more details)

qmt tests (e.g. brunel-upgrade-baseline) should differ by removed "<beta*ePrs>"-related counters.

  1. tried to remove IIncidentListener from CaloFutureCorrectionBase and changed FutureClusterCovarianceMatrixTool accordingly, relying on update of cached condition values by updMgrSvc.

The tests seem to be passing ok, but I'm not actually sure if what I did is fully correct. IIUC, the original code worked as follows (relying on handle(Incident)):

  • initially (and most of the time) CaloFutureCorrectionBase::m_update = false;
  • when updMgrSvc updates conditions in an instance of CaloFutureCorrectionBase, m_update is reset to true until the following EndEvent incident
  • at each BeginEvent incident FutureClusterCovarianceMatrixTool (including CaloFutureCorrectionBase as its member m_dbAccessor) checks if m_dbAccessor.m_update == true and if yes, it re-reads the values of the condition variables, which have been read on this event by m_dbAccessor, and updates its own cache of condition-dependent parameters.

I removed IIncidentListener and added registration of FutureClusterCovarianceMatrixTool to updMgrSvc so that when an update happens, FutureClusterCovarianceMatrixTool::setEstimatorParams_wrapper() gets invoked, which updates its cached condition parameters.

On one had in Gaudi::Functional the tools should not have internal caches for thread-safety. On the other hand, the cached parameters of these tools (CaloFutureCorrectionBase, its derived CaloFuture[ESL]Correction, as well as FutureClusterCovarianceMatrixTool) are EOV-wide and change extremely rarely. So does one need to extract such caches from the tools to the algorithm?

(Also, in order to properly test the functioning of the updates, one needs to prepare some test conddb switching between EOV's, and I already don't remember how to do that.)

Dear experts, could you please tell:

  • is it ok to remove IIncidentListener this way?
  • can events from different EOV's be run simultaneously in Gaudi::Functional ?
  • and if yes, then which object to register in the updMgrSvc? The algorithm, owning the cache which is extracted from the tool, or the tool, which better knows the structure of its cache? If possible, could you point to any code examples?
  • is there any simple example of how to create a local conddb layer with several artificial IOV's for tests

Many thanks in advance!

Dima

Edited by Marco Cattaneo

Merge request reports