TimeSim

This page is a draft, please help complete it!

This page page needs expert review!

Introduction

For practical reasons, events are first generated at a nominal time, not a realistic time. This allows the choice of time distribution to be delayed. It also might help in re-sampling events. At some point in the simulation, usually in the job when digis are made, the time is simulated and included in the time of the digi. The times are stored for primary SimParticles in a separate product SimParticleTimeMap which is then included in the digi-making process.

The final time of digis in simulation is always relative to the start of the microbunch, not a wall-clock time, so has values of 0 to 1695 ns. This is consistent with the way time will be handled in real beam data. The wall-clock time of the start of the microbunch will be stored elsewhere.

In the simulation, if a time is chosen by a physics process and that time is longer than 1695 ns, the time modulo 1695 ns is used. This has the effect of taking physics that would roll over to the following microbunches and putting it in this microbunch, under the philosophy that there are also earlier bunches with long times, that, with a long enough physics time, would appear in this bunch. This folding takes place in the digi-making modules.

There are two major times to consider. The first is the time of the primary proton interaction in the target. This is the instant that the generator will call a time of 0, but it really has variations on the order of 20 ns, primarily due to the length of the proton bunch. The second is the time that a stopped particle, usually a muon, decays or gets captured by the nucleus, a lifetime of 864 ns for Al.

Beam

There are two modules, one for each of the time that need to be generated.

protonTimeMap: { module_type : GenerateProtonTimes }
muonTimeMap: { module_type : GenerateMuonLife }

GenerateProtonTimes generates a shape approximately 20ns in width representing the variation in times that a protons hit the target. It makes a SimParticleTimeMap particle with a time for each primary SimParticle.

GenerateMuonLIfe generates an exponential time for the muon decay or capture. It makes a SimParticleTimeMap particle with a time for each primary SimParticle, if it was generated by a stopped particle generator.

They can be included:

physics:
{
    producers:
    {
        @table::EventMixing.producers
    }
}
...
    trigFilter: [@sequence::EventMixing.TimeMaps, ..]

Mu2eUtilities/src/SimParticleTimeOffsets.cc returns the time offset by summing all the relevant SimParticleTimeMap collections for a given SimParticle associated with a StepPointMC. The StepPointMC with this total time is then used to simulate detector response in the form of digis.

Stopped Particles

If a simulation jobs starts with a stopped particle, the input will be from an ntuple of stopped particle positions and times. The time in this ntuple is the time between the proton interaction and the stop. Since the stopped particle is a primary particle (and not a cosmic) it will be subject to the primary proton time simulation. Since it is a from a stopped particle generator, it is subject to the stopped muon lifetime simulation.

Mixing

No idea how this is all coordinated!

Cosmics

Cosmics are generated at a nominal time, in cd3, 800 ns after the start of the microbunch and the hits are fully contained in the event window. In the analysis, the cosmic topological lead to a time window around a cosmic candidate when a signal electron would be rejected. The time window can then moved and the result scaled to account for the efficiency on signal.

If the time modules are run on cosmic events, the particles from the cosmic will be ignored, based on the generator name, by the default settings. These settings can be overridden.