Allow GateAngleFilter to Exclude Particles Inside Cone

[TWJubb]

Currently the GateAngleFilter accepts a track if it lies within a particular angle of a specified axis,

https://github.com/OpenGATE/Gate/blob/8ee2c6932122cdb7b1faebf7bf0f378f672f3b21/source/general/src/GateAngleFilter.cc#L30

It could be helpful to add the ability to reverse this criteria to accept a track if it is outside the cone. A simple flag in the class would enable this by flipping the < to a > in the line above.

A use case for this would be, for example, looking at scattering from a pencil beam and killing all the tracks which pass straight through a phantom (this would be done by using the AngleFilter with a KillActor and specifying a small angle to exclude, rather than accept which is currently the only option).

[djboersma]

Actually, inverting the acceptance is such a basic operation that I wonder if it should be part of the GateVFilter base class.

Related to this, taking it a bit furhter: last week I discussed with @andiresch about what should be the desired behaviour when multiple filters are applied to an actor. Right now they are AND-ed, but I can imagine that sometimes you want them to be OR-ed. If users want it, we could maybe implement boolean expressions with filter names, something like:

/gate/MyActor/addFilter particleFilter isProton
/gate/MyActor/isProton/addParticle proton
/gate/MyActor/addFilter particleFilter isNeutron
/gate/MyActor/isNeutron/addParticle neutron
/gate/MyActor/addFilter angleFilter forward
/gate/MyActor/forward/setDirection 1 0 0
/gate/MyActor/forward/setAngle 90 deg
/gate/MyActor/filterLogic (isProton AND forward) OR (isNeutron AND NOT forward)

(Note that in this pseudo code the filters get individual names similar to how actors get names, which is currently NOT how it's done in Gate mac file grammar; for filters we use the filter type instead.)

Maybe this is more fancy than anyone needs. But I think that it would be a kind of generic solution to your specific feature request. However, implementing a generic filter logic parser is a bit more work than adding just a simple flag. :)

[tontyoutoure]

I don't think it would be necessary to implement something like a OR logic, probably you can just open a new instance running new conditional filter. But a NOT logic is definitely necessary.