ExposureCube calculations use efficiencyParameters from FRONT response functions for BACK response function calculations

[Areustle]

I suspect this is a bug, but I am not certain. The code is very tangled, with extreme long-range dependencies obfuscating the desired computation.

If it is a bug I think the effects are very minor, but still worth noting.

It seems that ExposureCube values for a given observation in Pass8 are calculated with IRFs for "Front" and "Back" effective areas, but only scaled by "Front" efficiency factors. If true, this would imply that "Back" responses are being treated as equivalently efficient to "Front".

The ExposureCube computation takes an arbitrary aeff functor, and a sky direction and energy, then computes an aeff exposure and optionally an aeff weighted exposure, both of which are scaled by efficiency factors computed from a member object m_efficiencyFactor whose getLivetimeFactors method does the computation.

Critically, this m_efficiencyFactor member is constructed with only the efficiency parameters from a single IRF, when the expCube object is constructed over in AppHelpers.

Where I think this becomes a bug is later on during computations involving expCube with different response functions, such as in MeanPsf.cxx during the exposure and meanPsfValue computations. In both cases the inner loop iterates over the vector of available response functions and generates Functors based on those IRFs, which are then passed to the already instantiated expCube object. Thus when the functors are generated from and compute values with the "Back" IRF, they are scaled by "Front" efficiency factors.

How big of a problem is this if at all?

On a first investigation is seems to be very minor. Here is a plot of the differing Front/Back factors for selected energies. The energies are taken from the 3C279 tutorial analysis thread observation. You can see they're very similar overlapping curves.

To understand how this would impact the exposure calculation for the observation I computed the exposure values for the source 4FGL J1118.2-0415 (The first point source in the srcmaps analysis thread's source list) using both the "Front-only" efficiency factors, and the appropriate "Front-Back" factors. Here you can see my intervention makes only a minuscule difference.

So it appears to be a very minor problem, at least for this one portion of the computation, but I'm still curious what the reasoning behind not using the appropriate efficiency factors are. I suspect it's an inflexibility in the layout of the likelihood code.

[phbruel]

Thanks Alex.

It looks like it's a bug.

The livetime efficiency mechanism is summarized in https://confluence.slac.stanford.edu/display/SCIGRPS/Livetime+depdence+of+effective+area
The plots for P8R3_v3 are shown in https://confluence.slac.stanford.edu/display/SCIGRPS/2014/06/03/Efficiency+correction+as+a+function+of+livetime+for+P8_V3+irfs

By definition, the correction is 1 when the livetime corresponds to the average livetime. So we don't expect any significant difference on a long period of time, but it could be different on a short period of time (during which the livetime was rather low = the deadtime was high).

Could you check what happens when analyzing the data with the PSF event types ? Does the correction factor always correspond to the PSF0 event type ?

[Areustle]

Hi Philippe,

Just examining the code I can say with high confidence that the answer will be yes, the correction factor will always correspond to a PSF0 event type in that case.

The offending method is in the ResponseFunctions.h header, and will only ever return the first set of factors. This return value is used to parameterize the expCube object. It is possible to alter these factors later on with ExposureCubes's setEfficiencyFactor method, but I have grepped Likelihood and found that it's only called in the one location in AppHelpers.cxx, so that's not happening elsewhere.

I will try to actually execute the code on a PSF event type IRF to confirm my expectation.