jturko
commented
6 years ago I haven't pushed any of my DESCANT related commits to the main branch yet. They are currently mixed in with a few other changes I have made for testing things which are not needed by anyone else in the collaboration. I think it makes the most sense just to add the specific changes that are needed for DESCANT to a newly forked branch and then push that.
The extended hit information needed for DESCANT are vectors to record the kinetic and deposited energies, the particle type, and the time for each interaction in the scintillator volume. There is also the option of creating a separate tree to hold this information which is only created if DESCANT is built in the simulation, which should keep things tidier and faster (hopefully) for all simulations without DESCANT.
On Tue, Mar 27, 2018 at 9:19 AM, Vinzenz Bildstein <notifications@github.com
wrote:
As histograms have been removed from the direct output of the simulation except for SPICE, the question came up whether we can add more information to the ntuple (mainly from the PrimaryGenerator, I believe).
Also, I think @jturko https://github.com/jturko already added something for DESCANT (though maybe those changes aren't pushed yet?).
This raised the question how we want to handle this. I'm a little bit sceptical about just adding everything into the tree, regardless of what is being simulated. This might slow the simulations down unnecessarily and also create bigger files than needed. But on the other hand I wouldn't want to fine-tune this too much and end up with having different columns be filled for each detection system that is being simulated.
So I thought the best idea would be to group things together, e.g. basic hit information (kind of what we got right now), extended hit information (stuff needed for DESCANT), and primary generator information (needed by SPICE, but maybe also interesting for others?).
We could also think about adding a third option besides having one entry per step or one entry per hit, and only write a single entry per detector?
Any thoughts or comments on this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/detectorSimulations_v10/issues/50, or mute the thread https://github.com/notifications/unsubscribe-auth/ALg8upAgtOmtgfwmk2mtqv7HIvOEpP0rks5tilhzgaJpZM4S9IBH .
As histograms have been removed from the direct output of the simulation except for SPICE, the question came up whether we can add more information to the ntuple (mainly from the PrimaryGenerator, I believe).
Also, I think @jturko already added something for DESCANT (though maybe those changes aren't pushed yet?).
This raised the question how we want to handle this. I'm a little bit sceptical about just adding everything into the tree, regardless of what is being simulated. This might slow the simulations down unnecessarily and also create bigger files than needed. But on the other hand I wouldn't want to fine-tune this too much and end up with having different columns be filled for each detection system that is being simulated.
So I thought the best idea would be to group things together, e.g. basic hit information (kind of what we got right now), extended hit information (stuff needed for DESCANT), and primary generator information (needed by SPICE, but maybe also interesting for others?).
We could also think about adding a third option besides having one entry per step or one entry per hit, and only write a single entry per detector?
Any thoughts or comments on this?