Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bug in decaying generators #235

Merged
merged 11 commits into from
Jun 21, 2024
Merged

Fix bug in decaying generators #235

merged 11 commits into from
Jun 21, 2024

Conversation

anthoak13
Copy link
Member

Fixes a bug where the beam and decays were both being generated in a single event.

This also has some initial work (used to fix bug) to more fully separate out "reaction" generators from "beam" generators. The reaction generators now all derive from a single class, and that class manages when the generators can add particles to the stack. If all is working properly, the user can ignore the two event structure and assume that if we are calling their GenerateReaction() function, then they should be producing particles.

@anthoak13 anthoak13 marked this pull request as ready for review June 15, 2024 04:34
@anthoak13 anthoak13 requested a review from Yassid June 16, 2024 20:12
anthoak13 added 11 commits June 20, 2024 19:57
Instead of counting the event number with three
different variables, we now use a single variable
that is a boolean to distinguish between the
beam-like half of the event and the reacion-like
half of the event.
Make the modification of the boolean more explicit
so the behavior is more clear.
This class covers if the generator should be run
or not depending on which type of event we are
runnning.

It should also handle if there is a child
generator that still needs to run and will only
mark the reaction event complete if all generators
have been run.
Because we are setting the event type at the end
of the generator phase (adding particles to the
primary track), we loose the information about
if it is reaction/beam in the stepping phase where
`ProcessHits` is called. To account for this we
use the trackID to determine what the event type
is. Alternatively, we could check
AtVertexPropogator we would just have to invert it

To account for hehavior in `AtTPC2Body` generator
added flag to `AtReactionGenerator` to allow for
any reaction to always run (even if it is a beam-
like event).
By definition, if an AtReactionGenerator is running
then it can create new particles. We should not
check for if it is a reaction event. That is
handled by the base class only and should be
hidden from users implementing generators.
- Move all tests to the same directory as the source files so they
are easier to locate in the project structure.
@anthoak13 anthoak13 merged commit c926e25 into ATTPC:develop Jun 21, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant