[EMCAL-566] Add executable for performing time and bad cell calibration#7886
[EMCAL-566] Add executable for performing time and bad cell calibration#7886shahor02 merged 2 commits intoAliceO2Group:devfrom
Conversation
[EMCAL-630] Force usage of references in range-based iteration over e…
mfasDa
left a comment
mfasDa
left a comment
There was a problem hiding this comment.
I think something entered in the CMakeLists by accident that needs to be fixed now. For what concerns the OMP thread allocation I guess this can be handled in the next iterations.
There was a problem hiding this comment.
The "TARGETVARNAME targetName" is needed for OpenMP. Based on O2/Detectors/TOF/calibration/CMakeLists.txt
There was a problem hiding this comment.
17644 threads is probably out of order for local machines :) Needs to be checked with @shahor02 and @chiarazampolli where to put the maximum here, I guess omp threads will need to be shared among components.
There was a problem hiding this comment.
Yes NCells is unrealistic. But like this it will use all available resources when calling the omp_get_max_threads(), right?
There was a problem hiding this comment.
We might want to use
o2::base::NameConf::getCCDBServer();introduced in #7778 as the default server path.
There was a problem hiding this comment.
@sawenzel @shahor02 Currently the o2::emcal::CalibDB is still using o2::ccdb::CcdbApi as underlying CCDB API. In principle it would be nice to migrate to o2::ccdb::BasicCcdbManager for the CCDB access, but the BasicCcdbManager does not provide write functions, which is i.e. used in this case. Do you see a problem adding a function storing objects which forwards to StoreAsTFileAny to the BasicCcdbManager? The goal of the o2::emcal::CalibDB is to provide a specific interface for EMCAL CDB access so users don't need to mess around with paths.
There was a problem hiding this comment.
@mfasDa the custom access to the CCDB from the user code in the workflows should be anyway outphased once the DPL CCDB service becomes functional.
jokonig
force-pushed
the
EMCAL-566
branch
4 times, most recently
from
05f1db3 to
1cacd4f
Compare
There was a problem hiding this comment.
I suspect this is to circumvent the problem with the multiple definition of TFormula when running with OMP threads > 1. This could become tricky in a multi-threaded environment. As far as I understand the variables should be allocated per thread (thread-local storage) based on our build settings. However would be good if we could find a way to avoid making members static.
|
@jokonig could you please apply changes suggested by the fullCI (braces)? |
- executable to run calibration, oth time and bad channel, in offline mode with local root histograms. Goal is to validate and debug the calibration using run2 data. - modified root to boost histogram conversion function: Specified the return type, corrected bin numbers for boost histograms - Added OpenMP option to cmake list. Goal is to parallelize the time-calibration as many independent fits are performed - Added implementation of time calibration in EMCALCalibExtractor
|
@shahor02 Should now be ready for merge. |
3 participants
executable to run calibration, both time and bad channel, in offline
mode with local root histograms. Goal is to validate and debug the
calibration using run2 data.
modified root to boost histogram conversion function: Specified the
return type, corrected bin numbers for boost histograms
Added OpenMP option to cmake list. Goal is to parallelize the
time-calibration as many independent fits are performed
Added implementation of time calibration in EMCALCalibExtractor