GammaLib

I implemented the reading of D2 X and Y interaction locations from the EVP file in GCOMEventList and GCOMEventAtom.

int m_fpmtflag;

• 0: all modules with failed PMTs are excluded from the DRE and DRG
• 1: all modules with failed PMTs are included into the DRE and DRG
• 2: events for zones around failed PMTs are excluded and the DRG is corrected correspondingly

The member can be accessed using GCOMSelection::fpmtflag() methods. The GCOMSelection::use_event() now also takes care of the module selection. Corresponding members have been added to keep track of the module selection.

The value of the m_fpmtflag member is written in the D2FPMT keyword in the DRE and DRG files. For DRE files, additional selection statistics concerning events rejected due to invalid modules are events rejected due to failed PMTs are also reported in the header.

The new logic is now used in the GCOMDri class, and specifically in the GCOMDri::compute_dre() and GCOMDri::compute_drg() methods. So far flag 2 is not yet supported since I need the zones to be excluded based on the FPM file for that. Yet I tested flag 0 (results as before) and flag 1 (including events from modules with failed PMTs), and things work as expected.

According to the module status table, here are the TJDs when the PMTs failed in a given D2 module:

For illustration, here is a plot of the interaction locations for VP 221 that also indicates the modules. The modules with failed PMTs appear smaller than the modules without failed PMTs. Exclusion regions from file MPE-FPM-7 are shown as black circles. D2 module 2 is actually fully excluded. The labelling of modules is for a top view. Note that the top plot is in log-scale while the bottom plot is in linear scale. The event distribution within a given module is not homogenous. Spikes of events correspond to the locations of the PMTs. A failed PMT is visible as a smearing of the corresponding spike.

I also added method to allow the selection of modules for DRI generation.

Below the DRG files for only D1 module 1 enabled using fpmtflag=0 (left), fpmtflag=1 (centre) and fpmtflag=2 for a short time interval. The binning was enhanced to 0.1° in Chi and Psi so that details of the DRG structure become visible. Note that the images are horizontally and vertically inverted with respect to the event location images shown above. Hence D2 module 2 is for example at the bottom centre.

The code operates as expected, with faulty modules excluded for fpmtflag=0 (left), all modules included for fpmtflag=1 (centre), and modules partially excluded for fpmtflag=2. Note that for the partial exclusion, D2 module 2 (at the bottom in these images) is always excluded. The three D2 modules for which events are partially excluded are at the three spots at the top-left corner.

I check how the steps parameter in the GCOMDri::compute_overlap() method impacts the geometry function computation. The results are shown below for steps=25 (left; default), steps=50 (centre) and steps=100 (right). The exact value does not seem to have a perceptible impact on the results.

To make also a quantitative comparison, here the DRG difference maps between steps=50 and steps=25 (left) and steps=100 and steps=25 (left). The increased number of integration steps becomes visible in form of lines along X and Y. The differences are indeed tiny. In term of integrated probabilities, the DRG content changes from 301387 for steps=25, to 301296 for steps=50, to 301169 for steps=100, hence a change of less than 0.1%.

Since I observed a lower number of counts for the D2-03 module in the 0.75-1 MeV energy band I checked whether there is an obvious module dependent energy threshold. This seems not to be the case, as illustrated below. The E1 and E2 thresholds for all events seems to be around 75 keV.

However, when plotting the total energy spectra as function of D1 and D2 module some differences become visible. Specifically, D2-02 has a significantly higher threshold, yet this module is generally excluded from the analysis (probably due to PMT failures). There are quite some variations in the total energy threshold, which may explain why the 0.75-1 MeV band is problematic.

The handling is implemented and well verified. I close the issue now.