INMUON functor

The INMUON functor (InMuonAcceptance) is needed e.g. for lines with fake muons, and widely used in the SL group (and probably others as well).

@jugarcia @mvesteri @poluekt

mentioned in merge request Moore!1151 (merged)

added ThOr label

I guess that INMUON is part of the muon ID information so it should be straightforward to make the functor.

Hello, should we probably target having a consistent set of functors to access the subdetector acceptance information? Such as hasCalo, hasRich, hasMuon in Run 2?

Yes we should think about the naming scheme. The names should try to reflect the precise meaning of these flags, which we should find out from the subdetector/algorithm people. In and Has have subtly different meanings in my [naive] picture.

Yes In and Has are different things. We need a consistent set of both.

mentioned in merge request Moore!1243 (merged)

marked this issue as related to #170

After some discussion with @sklaver I think this topic could be a good task for @yingl (a student at LZU).

If there are no objections, @yingl would start would start working on this in upcoming days.

InMuon functor is now implemented, merged and available in master. Many thanks to @yingl for implementing it.

mentioned in merge request !2926 (merged)

assigned to @yingl

During the development @yingl found that implementing HasMuon functor would need additional changes in the MuonPID code itself as no specific function corresponding to Run2 information is not present in the current code.

@sklaver @jugarcia @mvesteri @poluekt Could you comment on the exact usage of HasMuon and if it is needed in same form as in Run2?

Maybe @rvazquez has some thoughts? HasMuon seems a bit redundant in the Run-3 event model, but maybe I'm too naive...

I also think that having both for the muon is a bit redundant. InMuonAcceptance is filled if a track has p>3GeV and the extrapolation goes inside the muon acceptance. If this criteria are not met there is no sense in having a MuonPID. I don't think a specific functor for the momentum is needed because is a trivial check. So for the muon system there is only a muonPID if it is in the acceptance. So InMuon and HasMuon are the same thing. For other subdetectors, do InCalo/InRich and HasCalo/HasRich exist? Maybe for the sake of consistency with the other subdetectors, the Run2 InMuon functor needs to be renamed HasMuon in Run3

Maybe @cmarinbe can comment on the calo?

@cmarinbe Would you have any ideas about this?

mentioned in issue #399