IsoPsRefl amplitude optionally reads the beam polarization (eps-vector) direclty from an input tree

[iljatt]

IsoPsRefl.cc is updated together with the ancillary functions for angles calculation, histogram generation, etc.
Now, the format of eps-vector is implemented, analogously to Zlm.cc.

[gluex]

Build status for this pull request: FAILURE

Build log: make_ilbelov_3pi_fits.log
Build report: report_ilbelov_3pi_fits.txt

[gluex]

Build status for this pull request: FAILURE

Build log: make_ilbelov_3pi_fits.log
Build report: report_ilbelov_3pi_fits.txt

[gluex]

Build status for this pull request: FAILURE

Build log: make_ilbelov_3pi_fits.log
Build report: report_ilbelov_3pi_fits.txt

[gluex]

Test status for this pull request: SUCCESS

Summary: summary.txt
Logs: results/log

Build log: make_ilbelov_3pi_fits.log
Build report: report_ilbelov_3pi_fits.txt

[edbarriga]

Here are my comments for the different files:

decayAngles.cc:
-I looked at how the Zlm.cc file calculates the bigPhi/phiProd (line 124). The calculation for it differs from the one implemented in this code (line 130). Zlm uses the beam P4 in the lab frame, while decayAngles uses the beam P4 (or target) in the CM frame
-I suggest using const type& value to avoid copying the TLorentzVectors and the TVector3. My understanding is that this would increase the function's performance (line 94) [doing the same for other functions in decayAngles.cc would be good too]

Iso_ps_refl.cc
-I suggest closing and deleting the pointer for the TFile manually to prevent memory leaks. Furthermore, the TFile owns the histogram polFrac_vs_E, which is declared in the header file. This means that once the TFile is closed, TH1D* polFrac_vs_E no longer points to a valid address. This can be solved by detaching the histogram from the TFile: m_polFracVsE->SetDirectory(0); . The concern is that the histogram is used later in the code (lines 140-143)
-I would also suggest supplementary comments that give insight into what the arguments beyond the sixth are expected to be. Something short, like it is done in lines 52-58
-The eps vector (line 110) can be moved inside the if statement on line 131. This is because when m_polInTree is false, the eps vector is not used

IsoPsPlotGenerator.cc
-I would strongly encourage that the arguments are parsed in the constructor before the computations. This was done for VecPsPlotGenerator.cc, and it greatly improves the efficiency of the code.
-There might be an error in the parsing. The parsing of arguments in the amplitude input is not the same as the parsing of arguments for the amplitude list. So, could you confirm that beam_polAngle is args[6] as suppose to args[7]?
-The beam X and Y components are forcibly set to 0, but this is done after the beam was used to calculate the prod angle in lines 132 -138. Should the components be 0 before they enter these calculations?