Bug #16038
SpaceCharge service provider does not behave correctly when corrections are disabled
100%
Description
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.
When 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.
Associated revisions
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .
History
#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.
#2 Updated by Gianluca Petrillo almost 4 years ago
- Description updated (diff)
- % Done changed from 0 to 10
- Estimated time set to 1.00 h
#3 Updated by Gianluca Petrillo almost 4 years ago
The representation type is not left uninitialised any more, but rather set to kUnknown.
More important, both spacecharge::SpaceChargeMicroBooNE::GetPosOffsets() and 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.
#5 Updated by Katherine Lato over 3 years ago
- Status changed from Resolved to Closed
SpaceChargeMicroBooNE now reacts correctly if corrections are disabled.
This solves issue #16038 .