Root output not recorded correctly for lost particles when not tracking secondaries.

Issue #185 resolved
William Shields created an issue

When running an example machine using the tracking testing code, 60 out of 81 particles are lost (on purpose). The example machine, beam, options, and rootevent output are attached, ran with seed=2017. Secondaries are not tracked.

There is only one sampler, at the end of the machine in which s, zp, and n record 81 hits despite 60 of those actually being lost.

Comments (6)

  1. Laurie Nevay

    I think this is actually as expected. s, zp and n have only 1 entry per event as opposed to the others which are vectors. The whole sampler tree is recorded per event. When you double click on the variable in a root tree browser it adds together all events to make the histogram.

    For an event where nothing hit the sampler, the sampler structure still exists and is written - ie with empty vectors and n=0. So this still counts as an entry.

    In your file, for dr2.n you have 81 entires, but 61 of which are 0. So in 61 events there were 0 hits in that sampler.

    Screen Shot 2017-03-03 at 15.51.57.png

  2. William Shields reporter

    Apologies, in my initial message I didn't mean to include zp.

    I understand that with n, but for S, it seems counter-intuitive that lost particles are recorded in the final sampler as having an S position of zero when we know that the sampler's S position is not zero.

    Should we be recording an S position of 0 in the sampler to represent the position of a particle that never hit the sampler in the first place?

  3. Laurie Nevay

    Typo on my part. zp can vary. z is just an int. You can see what's what in BDSOutputROOTEventSampler.hh.

    I believe we have to have the default constructed instance of the class each time we fill the Event tree even if there were no hits in that particular sampler.

    I'll check with Stewart though.

  4. Laurie Nevay

    After discussion and understanding, will close this. In future z and S won't be stored in the sampler, even as an int as they're recorded per event. These can be looked up from the model tree where the information is also recorded. This was foreseen as a later optimisation, but definitely by version 1.0.

  5. Log in to comment