Staging: Difference between revisions
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
{{Expert}} | {{Expert}} | ||
==Introduction== | ==Introduction== | ||
Mu2e [[Simulation|simulation]] often uses a technique called staging. The idea is that an event is generated and simulated only partially then the simulation over that event is stopped and the event is written out. The next stage reads in the first stage, continues the simulation further, then stops and writes it out. Several stages may be used to complete a simulation. A stage may stop when all particles have reached a certain plane or a volume. A typical volume to stop a simulation on would be the DS region containing the target and the detector, or a volume that contains the tracker. Another example of a end of stage is when all muons have stopped in the, but not decayed. | |||
The motivations for staging are below. They are all especially important if the early stages dominate the CPU time, which is usually the case in mu2e. | |||
* A piece of the detector can be defined in a later stage. For example, all the computationally-expensive protons on target can be simulated for months, and the simulation stopped outside the production target. During this time, the tracker geometry can continue to develop. When the tracker description, is ready the simulation can be continued into the tracker volume. | |||
* Variations in design can be studied efficiently. If a simulation stage is stopped outside of a detector, then the simulation can be continued using different design of the detector. Each design can be tested quickly because all the simulation before the detector doesn't have to be repeated. | |||
* Staging can make error recovery much more efficient. If a mistake is discovered in stage 3, then stage 3 can be repeated without repeating stages 1 and 2. When most of the CPU time is spent in the early stages, this can | |||
* There are often limitations in how long a job can run or how large an output file can be, that can be efficiently handled with staging. Sometimes it helps to compress and drop information before continuing, or filter events for more efficient storage, or concatenate. See [[JobPlan|job planning]] for more discussion. | |||
Staging also enables two more important simulation techniques, such as [[MIxing|mixing]] and resampling, see [[Simulation]]. | |||
==Examples== | |||
Stages are often abbreviated as '''s1''', '''s2''', etc. The following examples reflect the cd3 staging plan. These stages are designed to meet many needs of the collaboration. User might typically start their work with one of the sample of the higher stages, depending on the analysis goals. | |||
===Beam=== | |||
* '''s1''' - generate primary protons, simulate up to TS2. This is the majority of the CPU. | |||
** write out particles that are in the transport channel to the "mubeam" dataset | |||
** write particles that are approaching the outside of the CRV to the "dsregion" dataset | |||
** write particles that are approaching extmon their own dataset | |||
** allows variations in the CRV, TS3 foils, but locks in any TS1 foils. | |||
* '''s2''' - continue the s1 mubeam simulation through TS4, stop on the boundary of TS5. | |||
** write out result to s2 mubeam dataset | |||
** allows the variation of TS5 materials and anything downstream - the target, the detector, etc. | |||
* '''s3''' - continue the s2 mubeam simulation to the outside of the tracker and calorimeter | |||
** for muons stopped in the target, write them out to an ntuple, remove them from the simulation | |||
** for muons stopped everywhere else, stop their simulation and write them to the "ootstops" dataset | |||
** write everything else to "mothers" dataset | |||
* '''s4''' - finally simulate the detector. This is s series of different jobs, creating many datasets which will be brought back together in [[mixing]]. | |||
** read s3 mothers, simulate the detector, write to "flash" dataset | |||
** read s3 ootstops, simulate the detector, write to "detoot" dataset | |||
** read target stopped muons, force decay to DIO, simulate the detector, write to "detdio" dataset | |||
** read target stopped muons, force capture and production of photon, neutron, proton, deuterons, write each to its own dataset | |||
** generate conversion electrons from scratch (will be mixing later), write to "detconversion" dataset | |||
** generate conversion electrons from scratch, flat momentum spectrum, write to "flate" dataset | |||
These many datasets are typically [[Mixed|mixed]] for different purposes. | |||
===Neutrons=== | |||
===Cosmics=== | |||
==Other Staging== | ==Other Staging== | ||
time. turning off decays... | time. turning off decays... |
Revision as of 21:31, 20 April 2017
This page is a draft, please help complete it!
This page page needs expert review!
Introduction
Mu2e simulation often uses a technique called staging. The idea is that an event is generated and simulated only partially then the simulation over that event is stopped and the event is written out. The next stage reads in the first stage, continues the simulation further, then stops and writes it out. Several stages may be used to complete a simulation. A stage may stop when all particles have reached a certain plane or a volume. A typical volume to stop a simulation on would be the DS region containing the target and the detector, or a volume that contains the tracker. Another example of a end of stage is when all muons have stopped in the, but not decayed.
The motivations for staging are below. They are all especially important if the early stages dominate the CPU time, which is usually the case in mu2e.
- A piece of the detector can be defined in a later stage. For example, all the computationally-expensive protons on target can be simulated for months, and the simulation stopped outside the production target. During this time, the tracker geometry can continue to develop. When the tracker description, is ready the simulation can be continued into the tracker volume.
- Variations in design can be studied efficiently. If a simulation stage is stopped outside of a detector, then the simulation can be continued using different design of the detector. Each design can be tested quickly because all the simulation before the detector doesn't have to be repeated.
- Staging can make error recovery much more efficient. If a mistake is discovered in stage 3, then stage 3 can be repeated without repeating stages 1 and 2. When most of the CPU time is spent in the early stages, this can
- There are often limitations in how long a job can run or how large an output file can be, that can be efficiently handled with staging. Sometimes it helps to compress and drop information before continuing, or filter events for more efficient storage, or concatenate. See job planning for more discussion.
Staging also enables two more important simulation techniques, such as mixing and resampling, see Simulation.
Examples
Stages are often abbreviated as s1, s2, etc. The following examples reflect the cd3 staging plan. These stages are designed to meet many needs of the collaboration. User might typically start their work with one of the sample of the higher stages, depending on the analysis goals.
Beam
- s1 - generate primary protons, simulate up to TS2. This is the majority of the CPU.
- write out particles that are in the transport channel to the "mubeam" dataset
- write particles that are approaching the outside of the CRV to the "dsregion" dataset
- write particles that are approaching extmon their own dataset
- allows variations in the CRV, TS3 foils, but locks in any TS1 foils.
- s2 - continue the s1 mubeam simulation through TS4, stop on the boundary of TS5.
- write out result to s2 mubeam dataset
- allows the variation of TS5 materials and anything downstream - the target, the detector, etc.
- s3 - continue the s2 mubeam simulation to the outside of the tracker and calorimeter
- for muons stopped in the target, write them out to an ntuple, remove them from the simulation
- for muons stopped everywhere else, stop their simulation and write them to the "ootstops" dataset
- write everything else to "mothers" dataset
- s4 - finally simulate the detector. This is s series of different jobs, creating many datasets which will be brought back together in mixing.
- read s3 mothers, simulate the detector, write to "flash" dataset
- read s3 ootstops, simulate the detector, write to "detoot" dataset
- read target stopped muons, force decay to DIO, simulate the detector, write to "detdio" dataset
- read target stopped muons, force capture and production of photon, neutron, proton, deuterons, write each to its own dataset
- generate conversion electrons from scratch (will be mixing later), write to "detconversion" dataset
- generate conversion electrons from scratch, flat momentum spectrum, write to "flate" dataset
These many datasets are typically mixed for different purposes.
Neutrons
Cosmics
Other Staging
time. turning off decays...