Continuous time simulation of decays (especially for Bi207 calibration)

[pguzowski]

WIth 2kBq Bi207 sources, and 24 sources, there will be a decay every ~20μs. This means decays will overlap within the same trigger readout window. Also delayed particles in each decay will overlap with future decay windows (where the delay could be up to a few seconds later -- see for example the electron and gamma times in the event display in #4)

We require a more sophisticated handling of continuous time events in the simulation, rather than event by event processing of a single generated decay.

An idea for a module to do this: generate a single 'event' with X total decays at some rate Y Hz (randomly distributed in time), and then have the trigger simulation split them up into N triggered readout-window-sized events after digitisation.

[goliviero]

An other example is the BiPo 214 cascade. An alpha particle is 'delayed' in relation to the 'prompt' electron but in the real world other physical events can happen between the electron/alpha decay.
In G4/Bayeux, the bipo cascade is 1 event but in the detector it will be 2 events.
An other idea is to split the G4 event into 2 events with a special flag for the alpha particle to know from which electron it comes from.

[goliviero]

Other thing to take into account in Falaise : the dead time of the detector
Once a Geiger cell is hit, the cell is 'dead' during 1ms.
This will be implemented in the Analog Signal Builder / Digitization modules

[fmauger]

This is a complex and interesting problem. We (Guillaume, Yves, I) have postponed the work to be done about this use case. There is no unique strategy. My feeling is that we should implement a solution which approximates a continuous decay time model because it is not so compatible with the event- per-event approach of G4 itself and it would be possibly extremely CPU consuming if implemented with brute force.
We have to think about it more deeply. It is also difficult to implement a solution without having the proper implementation of the digitization module with almost all the technical details.
To begin, I would implement an effective generator approximating Bi207 with only the useful lines with
respect to the SN trigger strategy. Basically, it implies to implement some kind of multivertex decay generators connected both to the geometry and bxgenvtx and bxgenbb_help and filtered with a reasonable time integration window to limit the time range to be injected in the simulation and digitization modules.
it is not clear to me if it would need a dedicated module prepend before the simulation module (this would
imply interesting modifications in Bayeux) or a dedicated smart event generator as mentioned above.
So, to be discussed...

[pguzowski]

I have uploaded a brio file that I have generated with a custom genbb & genvtx module, with 48kBq Bi207 source activity & 1ms readout window size: http://www.hep.manchester.ac.uk/u/pguzowski/bi207/flsimulate_48kBq_Bi207_srcs_1ms_readout.brio
I hope this is a useful starting point for people to try out in flreconstruct

[drbenmorgan]

@pguzowski Is the code for the custom module(s) available anywhere? In relation to #31 it would be a good test/example of the required functionality!

[pguzowski]

I have uploaded the code to: https://github.com/pguzowski/snemo_hi_freq_simulation

It isn't really documented, as for now it was just me playing around with it.

Also it uses singleton-style functionality with static class members, because I needed the event generator to communicate with the vertex generator, so you probably won't like it from a good-coding perspective

[drbenmorgan]

Thanks @pguzowski! No problem on the statics - can always be fixed later if required.