TimeSim: Difference between revisions

From Mu2eWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 11: Line 11:
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.
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.


==Modules==
==Beam==
There are two modules, one for each of the time that need to be generated.
There are two modules, one for each of the time that need to be generated.
<pre>
<pre>
Line 21: Line 21:


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.
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:
<pre>
physics:
{
    producers:
    {
        @table::EventMixing.producers
    }
}
...
    trigFilter: [@sequence::EventMixing.TimeMaps, ..]
</pre>


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.
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.


==Beam==
===Mixing===
===Mixing===


==Stopped Particles==
===Stopped Particles===


==Cosmics==
==Cosmics==

Revision as of 18:40, 19 April 2017

Construction.jpeg This page is a draft, please help complete it!

Expert.jpeg 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.

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.

Mixing

Stopped Particles

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.