SpaceCharge service provider does not behave correctly when corrections are disabled
The behaviour of
SpaceChargeMicroBooNE service provider is undefined when the corrections are not enabled.
The type of correction is not initialised when the corrections are not requested.
GetPosOffset() is called, the provider always attempts to compute a correction, even when corrections are disabled.
The way this attempt is performed depends on the type of correction. When the correction is disabled and the correction type is not defined, the action is also unpredictable.
LArG4, the only user to date, calls the correction only when the correction is enabled
- the failure of the unit test is still to be explained
The same is likely true for the electric field distortion.
Thanks to Varuna Meddage and Tingjun Yang for reporting the problem.
#1 Updated by Gianluca Petrillo almost 4 years ago
- Status changed from New to Assigned
- Assignee set to Gianluca Petrillo
The lack of failure in the test is understood.
I was expecting to see an assertion failure from
SpaceChargeMicroBooNE, which was not observed.
While it is true that in the test area assertions are always enabled, since I am running in profiling mode the assertions are not even compiled in in the libraries (as
libuboone_SpaceCharge_SpaceChargeMicroBooNE.so), because the libraries are outside of the test area. Therefore those assertions can't be triggered.
#3 Updated by Gianluca Petrillo almost 4 years ago
The representation type is not left uninitialised any more, but rather set to
More important, both
spacecharge::SpaceChargeMicroBooNE::GetEfieldOffsets() immediately return a null correction vector if the respective correction is disabled.
A fix was pushed in
develop branch as eb3e675929aee40ebc8d63d8b0e7c321c369ae19 .
#4 Updated by Gianluca Petrillo almost 4 years ago
- Status changed from Assigned to Resolved
- % Done changed from 10 to 100
As a final note: a failure in the unit test was also observed and reported by Herbert Greenlee, but the failure is just occasional, the root cause being an undefined state.
For that reason it was not noticed during the release cutting procedures by LArSoft first, and MicroBooNE then.