Closed gondiaz closed 2 years ago
I would say that in the interactive mode there is no need to use DefaultEventAction
either, since one is not concerned with how many events are saved in the output file. One could simply use the default actions by not specifying any custom actions.
In fact, if one wanted to save only events with energy deposition above a threshold, and at the same time is not using DefaultTrackingAction
, it wouldn't work, because the calculated energy deposited would be always zero. I will document the use of each action better, once the PR on the clean-up of the actions is approved.
What we could do is, instead of adding a protection, adding a meaningful error message and let the program crash.
Agree. What do you think about placing such an error before the SetUserAction
in NexusApp.cc
? This would assure that you always choose a compatible set of user actions
Agree. What do you think about placing such an error before the
SetUserAction
inNexusApp.cc
?
I don't like it vey much, I would prefer to keep the code in the NexusApp
class as simple as possible. I would rather put the protection in DefaultEventAction
, which is the class that accesses the Trajectory object
.
@gondiaz, what about this PR? Are you going to add the comment to the crash or shall we close it?
At least not in the next two weeks
At least not in the next two weeks
This doesn't answer my question :-).
The answer is yes then, but I don't know when. If it is annoying to have this pending, it can be closed. If anyone wants to contribute and finish it, also works for me.
It's not annoying, I just want to know if you forgot about it or you are going to finish it at some point.
In interactive mode, you might want to use DefaultEventAction without DefaultTrackingAction. Since you are in interactive mode, Geant4 will provide a not empty
G4TrajectoryContainer
, which is a vector ofG4VTrajectory
. The dowcast fails sinceTrajectory
is a nexus class.