Photon Gradient Boosted Tree Filter

[Gregtom3]

Photon GBT Filter

Description

At CLAS12, neutral particles such as photons are often falsely reconstructed. For instance, events without a true SIDIS photon, say, from a neutral pi0 decay, will still contain reconstructed photons in the REC::Particle bank. These photons are false backgrounds for many physics channels. A new algorithm titled PhotonGBTFilter was added to the repository to filter out this false photon background.

Models trained on RGA inbending, RGA outbending, and RGC Monte Carlo were produced. Future plans are to include models for RGK, as well as distinct models for pass1 vs. pass2 cooking.

A validator algorithm was also provided in the PR. This algorithm can be run by...
meson test validator-clas12-PhotonGBTFilter --verbose --test-args '\-f /cache/clas12/rg-a/production/recon/fall2018/torus-1/pass1/v1/dst/train/nSidis/nSidis_005032.hipo \-n 0 \-o ../validator_output' ...below is the output

[c-dilks]

Please add yourself and your code to the CODEOWNERS file (it's how we keep track of who maintains the algorithms)

[dglazier]

A couple of comments relating to integration with iguana. First the passing of the run number into the action would probably be best handled elsewhere in a manner used by all algorithms, it is a general issue. For example in a proposed ChangeRun function. In general this gives the action function less to do. Related, it looks like the models would benefit from class inheritance. You could then just construct the valid model for the run number in the ChangeRun function and avoid needing to reproduce code in the models. This would make is simpler to expand to further beam periods in the future. Alternatively it may be possible to move all the parameters into configuration files and just load them via the yaml readers and just require 1 model class at ChangeRun time to avoid any hard-coding. Or is there a reason why this would not work ?
Cheers
Derek

[c-dilks]

Some general comments, for future consideration:

• std::unordered_map lookups are rather slow, and should be avoided in the Run method or action functions where possible
• for compatibility with the diverse set of user analysis tools, action functions are only allowed to use basic parameter types, such as int and float; these are scalar action functions, and in the future we will also have vector action functions, which accept std::vector<int> etc. It looks like this algorithm should have a vector action function

[c-dilks]

First the passing of the run number into the action would probably be best handled elsewhere in a manner used by all algorithms, it is a general issue. For example in a proposed ChangeRun function. In general this gives the action function less to do.

@dglazier let's leave Gregory's run-dependent implementation as is here, and followup in #95.

[c-dilks]

CI results: