Rolf, I’m curious about the actual computational models you use.
How much is or can be simulated? Do the simulations cover only the exact spatial-temporal slice of the impact, or the entire accelerator, or what? Does the simulation environment include some notion of the detector?
And on that note, the Copenhagen interpretation has always bothered me in that it doesn’t seem computable. How can the collapse actually be handled in a general simulation?
I am a graduate student in experimental particle physics, working on the CMS experiment at the LHC. Right now, my research work mainly involves simulations of the calorimeters (detectors which measure the energy deposited by particles as they traverse the material and create “showers” of secondary particles). The main simulation tool I use is software called GEANT, which stands for GEometry ANd Tracking. (Particle physicists have a special talent for tortured acronyms.) This is a Monte Carlo simulation, i.e. one that uses random numbers. The current version of the software is Geant4, which is how I will refer to it.
The simulation environment does have an explicit description of the detector. Geant4 has a geometry system which allows the user to define objects with specific material properties, size, and position in the overall simulated “world”. A lot of work is done to ensure the accuracy of the detector setup (with respect to the actual, physical detector) in the main CMS simulation software. Right now, I am working on a simplified model with a less complicated geometry, necessary for testing upgrades to the calorimeters. The simplified geometry makes it easier to swap in new materials and designs.
Geant4 also has various physics lists which describe the various scattering and interaction processes that particles will undergo when they traverse a material. Different models are used for different energy ranges. The choice of physics list can make a significant difference in the results of the simulation. Like the geometry setup, the physics lists can be modified and tuned for better agreement with experimental data or to introduce new models. The user can specify how long the program should keep track of particles, as well as a minimum energy cutoff for secondary particles (generated in showers).
An often frustrating part of Geant4 simulations is that the computing time scales roughly linearly with the number of particles and the energy of the particles. One can mitigate this problem to some extent by running in parallel, e.g. submitting 10 jobs with 1000 events each, instead of one job with 10000 events. (Rolf talks about parallelization here.) However, as we keep getting more events with higher energies at the LHC, computing time becomes more of an issue.
Because of this, there is an ongoing effort in “fast simulation.” To do a faster simulation than Geant4, we can come up with parameterizations that reproduce some essential characteristics of particle showers. Specifically, we parameterize the distribution of energy deposited in the material in both the longitudinal and transverse directions. (For example, the longitudinal distribution is often parameterized as a gamma distribution.) The development of these parameterizations can be complicated, but once we have an algorithm, the simulation just requires evaluating the functions at each step. Fast simulation essentially occurs above the particle level, which is what makes it faster. A caveat: this is much easier for electromagnetic showers (which involve only electrons and photons, and only a few main processes for high energies) than for hadronic showers (which involve numerous hadrons and processes, because the strong force plays a crucial role, and therefore the energy distributions fluctuate quite a bit).
What I have given here is an overview of the simulation study of detectors; in all of this, we send single particles through the detector material. We do the same thing in real life, with a “test beam”, so that we can compare to data. The actual collisions at the LHC, however, produce events far more complex than a single particle test beam. We simulate those events, too (Rolf discusses some of that below), and there are even more complications involved. I am not as knowledgeable there (yet), and this post is long enough as it is, so I will hold off on elaborating. I hope this has given you some insight into modern particle simulations!
So the reason we simulate things is, basically, to tell us things about the detector, for example its efficiency. If you observe 10 events of type X after 100k collisions, and you want to know the actual rate, you have to know your reconstruction efficiency with respect to that kind of event—if it’s fifty percent (and that would be high in many cases) then you actually had 20 physical events (plus or minus 6, obviously) and that’s the number you use in calculating whatever parameter you’re trying to measure. So you write Monte Carlo simulations, saying “Ok, the D* goes to D0 and pi+ with 67.4% probability, then the D0 goes to Kspipi with 5% probability and such-and-such an angular distribution, then the Ks goes to pions pretty exclusively with this lifetime, then the pions are long-lived enough that they hit the detector, and it has such-and-such a response in this area.” In effect we don’t really deal with quantum mechanics at all, we don’t do anything with the collapse. (Talking here about experiments—there are theorists who do, for example, grid calculations of strong-force interactions and try to predict the value of the proton mass from first principles.) Quantum mechanics only comes in to inform our choice of angular distributions. (Edit: Let me rephrase that. We don’t really simulate the collapse; we say instead, “Ok, there’s an X% chance of this, so roll a pseudorandom number between zero and one; if less than X, that’s the outcome we’re going with. We don’t deal with the transition, as it were, from wave functions to particles.) The actual work is in ‘swimming’ the long-lived decay products through our simulation of the detector. The idea is to produce information in the same format as your real data, for example “voltage spike in channel 627 at timestamp 18”, and then run the same reconstruction software on it as on real data. The difference is that you know exactly what was produced, so you can go back and look at the generated distributions and see if, for example, your efficiency drops in particular regions of phase space. Usually it does, for example if one particle is slow, or especially of course if it flies down the beampipe and doesn’t hit the active parts of the detector.
Calibrating these simulations is a fairly major task that consumes a lot of physicist time and attention. We look at known events; at BaBar, for example, we would occasionally shut off the accelerator and let the detector run, and use the resulting cosmic-ray data for calibration. It helps that there are really only five particles that are long-lived enough to reach the detector, namely pion, kaon, neutron, electron, and proton; so we can study how these particles interact with matter and use that information in the simulations.
Another reason for simulating is to do blind studies. For example, suppose you want to measure the rate at which particle X decays to A+B+C. You need some selection criteria to throw away the background. The hihger your signal-to-noise ratio, the more accurately you can measure the rate, within some limits—there’s a tradeoff in that the more events you have, the better the measurement. So you want to find the sweet spot between 0 data of 100% purity and 100% of the data at 2% purity. (Purity, incidentally, is usually defined as signal/(signal+background).) But you usually don’t want to study the effects of your selections directly on data, because there’s a risk of biasing yourself—for example, in the direction of agreement with a previous measurement of the same quantity. (Millikan’s oil drops are the classic example, although simulations weren’t involved.) So you tune your cuts on Monte Carlo events, and then when you’re happy with them you go see if there’s any actual signal in the data. This sort of thing is one reason physicists are reasonably good about publishing negative results, as in “Search for X”; it could be very embarrassing to work three years on a channel and then be unable to publish because there’s no signal in the data. In such a case the conclusion is “If there had been data of such-and-such a level, we would have seen it (with 95% probability); we didn’t; so we conclude that the process, if it occurs, has a rate lower than X”.
Rolf, I’m curious about the actual computational models you use.
How much is or can be simulated? Do the simulations cover only the exact spatial-temporal slice of the impact, or the entire accelerator, or what? Does the simulation environment include some notion of the detector?
And on that note, the Copenhagen interpretation has always bothered me in that it doesn’t seem computable. How can the collapse actually be handled in a general simulation?
I am a graduate student in experimental particle physics, working on the CMS experiment at the LHC. Right now, my research work mainly involves simulations of the calorimeters (detectors which measure the energy deposited by particles as they traverse the material and create “showers” of secondary particles). The main simulation tool I use is software called GEANT, which stands for GEometry ANd Tracking. (Particle physicists have a special talent for tortured acronyms.) This is a Monte Carlo simulation, i.e. one that uses random numbers. The current version of the software is Geant4, which is how I will refer to it.
The simulation environment does have an explicit description of the detector. Geant4 has a geometry system which allows the user to define objects with specific material properties, size, and position in the overall simulated “world”. A lot of work is done to ensure the accuracy of the detector setup (with respect to the actual, physical detector) in the main CMS simulation software. Right now, I am working on a simplified model with a less complicated geometry, necessary for testing upgrades to the calorimeters. The simplified geometry makes it easier to swap in new materials and designs.
Geant4 also has various physics lists which describe the various scattering and interaction processes that particles will undergo when they traverse a material. Different models are used for different energy ranges. The choice of physics list can make a significant difference in the results of the simulation. Like the geometry setup, the physics lists can be modified and tuned for better agreement with experimental data or to introduce new models. The user can specify how long the program should keep track of particles, as well as a minimum energy cutoff for secondary particles (generated in showers).
An often frustrating part of Geant4 simulations is that the computing time scales roughly linearly with the number of particles and the energy of the particles. One can mitigate this problem to some extent by running in parallel, e.g. submitting 10 jobs with 1000 events each, instead of one job with 10000 events. (Rolf talks about parallelization here.) However, as we keep getting more events with higher energies at the LHC, computing time becomes more of an issue.
Because of this, there is an ongoing effort in “fast simulation.” To do a faster simulation than Geant4, we can come up with parameterizations that reproduce some essential characteristics of particle showers. Specifically, we parameterize the distribution of energy deposited in the material in both the longitudinal and transverse directions. (For example, the longitudinal distribution is often parameterized as a gamma distribution.) The development of these parameterizations can be complicated, but once we have an algorithm, the simulation just requires evaluating the functions at each step. Fast simulation essentially occurs above the particle level, which is what makes it faster. A caveat: this is much easier for electromagnetic showers (which involve only electrons and photons, and only a few main processes for high energies) than for hadronic showers (which involve numerous hadrons and processes, because the strong force plays a crucial role, and therefore the energy distributions fluctuate quite a bit).
What I have given here is an overview of the simulation study of detectors; in all of this, we send single particles through the detector material. We do the same thing in real life, with a “test beam”, so that we can compare to data. The actual collisions at the LHC, however, produce events far more complex than a single particle test beam. We simulate those events, too (Rolf discusses some of that below), and there are even more complications involved. I am not as knowledgeable there (yet), and this post is long enough as it is, so I will hold off on elaborating. I hope this has given you some insight into modern particle simulations!
So the reason we simulate things is, basically, to tell us things about the detector, for example its efficiency. If you observe 10 events of type X after 100k collisions, and you want to know the actual rate, you have to know your reconstruction efficiency with respect to that kind of event—if it’s fifty percent (and that would be high in many cases) then you actually had 20 physical events (plus or minus 6, obviously) and that’s the number you use in calculating whatever parameter you’re trying to measure. So you write Monte Carlo simulations, saying “Ok, the D* goes to D0 and pi+ with 67.4% probability, then the D0 goes to Kspipi with 5% probability and such-and-such an angular distribution, then the Ks goes to pions pretty exclusively with this lifetime, then the pions are long-lived enough that they hit the detector, and it has such-and-such a response in this area.” In effect we don’t really deal with quantum mechanics at all, we don’t do anything with the collapse. (Talking here about experiments—there are theorists who do, for example, grid calculations of strong-force interactions and try to predict the value of the proton mass from first principles.) Quantum mechanics only comes in to inform our choice of angular distributions. (Edit: Let me rephrase that. We don’t really simulate the collapse; we say instead, “Ok, there’s an X% chance of this, so roll a pseudorandom number between zero and one; if less than X, that’s the outcome we’re going with. We don’t deal with the transition, as it were, from wave functions to particles.) The actual work is in ‘swimming’ the long-lived decay products through our simulation of the detector. The idea is to produce information in the same format as your real data, for example “voltage spike in channel 627 at timestamp 18”, and then run the same reconstruction software on it as on real data. The difference is that you know exactly what was produced, so you can go back and look at the generated distributions and see if, for example, your efficiency drops in particular regions of phase space. Usually it does, for example if one particle is slow, or especially of course if it flies down the beampipe and doesn’t hit the active parts of the detector.
Calibrating these simulations is a fairly major task that consumes a lot of physicist time and attention. We look at known events; at BaBar, for example, we would occasionally shut off the accelerator and let the detector run, and use the resulting cosmic-ray data for calibration. It helps that there are really only five particles that are long-lived enough to reach the detector, namely pion, kaon, neutron, electron, and proton; so we can study how these particles interact with matter and use that information in the simulations.
Another reason for simulating is to do blind studies. For example, suppose you want to measure the rate at which particle X decays to A+B+C. You need some selection criteria to throw away the background. The hihger your signal-to-noise ratio, the more accurately you can measure the rate, within some limits—there’s a tradeoff in that the more events you have, the better the measurement. So you want to find the sweet spot between 0 data of 100% purity and 100% of the data at 2% purity. (Purity, incidentally, is usually defined as signal/(signal+background).) But you usually don’t want to study the effects of your selections directly on data, because there’s a risk of biasing yourself—for example, in the direction of agreement with a previous measurement of the same quantity. (Millikan’s oil drops are the classic example, although simulations weren’t involved.) So you tune your cuts on Monte Carlo events, and then when you’re happy with them you go see if there’s any actual signal in the data. This sort of thing is one reason physicists are reasonably good about publishing negative results, as in “Search for X”; it could be very embarrassing to work three years on a channel and then be unable to publish because there’s no signal in the data. In such a case the conclusion is “If there had been data of such-and-such a level, we would have seen it (with 95% probability); we didn’t; so we conclude that the process, if it occurs, has a rate lower than X”.