Bug #840
Simulation energy increasing in tracker?
0%
Description
There is a rumour that the tracker group have observed energy increasing in the tracker. But no bug has been logged.
Couple of things it could be:
- Incorrect labelling of Tracker - getting confused between us and ds tracker (there's RF in between)
- Getting confused between primary and decay products - decay electrons often have higher energy than the originating muon, especially for low energy (e.g. stopping) muons
Could you please attach some sample output that demonstrates the bug so I can investigate?
Files
Updated by Rogers, Chris almost 12 years ago
Just a note - I did run 1000 particles through Stage 6 and looked at output on virtual planes. I couldn't see any increasing energies. I can go to higher stats if you want. I just don't believe the bug report.
Updated by Blot, Summer almost 12 years ago
- File full_mausput_spacepoints full_mausput_spacepoints added
I am not entirely sure of the conditions for this simulation. I believe it was for a 140 MeV/c beam, not sure what emittance was intended though. I am not sure as to whether or not energy loss/multiple scattering was turned off. I believe it was run with Stage 6 configuration, and secondary particles turned off, so there shouldn't be any electrons. Ed ran the simulation to produce the spacepoints, so he should know what the conditions were.
If you take a look at like 6, for example, you can see that Pt increases from tracker 1 to tracker 2, and there is a significant decrease in Pz. Over all there were 419 spills recorded.
Updated by Rogers, Chris almost 12 years ago
- Workflow changed from New Issue to In Development
Summer, could you tell me which spill / track id has energy increasing? Or which spill/track id has the problem?
Updated by Blot, Summer almost 12 years ago
Sorry, typo in last update. 'If you look at LINE 6' which would correspond to spill 6, correct? You will see an increase in Pt as you go from the first to the second tracker.
In addition, if you look specifically at the first tracker, and sketch the x-y projeciton, you can see it has radius of roughly 5 mm. But that radius, combined with what the MC px and py, and using the equation
Pt = B * r * .3
you would get that the magnetic field would have to be about 8T to produce that radius with that Pt.
There are probably other spills with a similar increase, but this one is just the first. I can hunt through for the rest of them and let you know later today or tomorrow which ones are strange, but I'm pretty sure any time the particle makes it to tracker 2 something funny happens.
Updated by Rogers, Chris almost 12 years ago
Tracker 1 -> Tracker 2... you're in trouble here - all sorts of nasties await which could cause this sort of thing - putting the beam in with the wrong pt in the first place, plain old multiple scattering, resonances in the magnetic lattice. I think that whoever does the simulation need some crash course in accelerator physics to understand how the beam should look.
Updated by Rogers, Chris almost 12 years ago
- File example_sim.tgz example_sim.tgz added
Please have a go with the attached tarball. Try something like
source ~/maus/env.sh $MAUS_ROOT_DIR/bin/simulate_mice.py -configuration_file configuration.py python bunch_analysis.pySo I plot
- scatter plots of bx, by, bz - can see that the fields are 4 T in z, 0 in other directions as we hope.
- Transmission - can see that the transmission is of order 95%
- mean energy - can see mean energy loss is reasonable
- beta trans - well this looks a bit crap. For accelerator studies the fields aren't really correct and need to be fixed. Probably the magnetic lattice is too broken to cool. But it should work reasonably well for what you want to do. I didn't discard electrons so perhaps there are some particle decays skewing results also.
I can't say why one particle has the wrong radius, but I can guess that it is some effect of multiple scattering or other physics stuff. Here we see that statistically the bunch is well behaved, at least with the caveat of well the field map isn't quite perfect.
Cheers,
Chris
Updated by Dobbs, Adam almost 12 years ago
Looking at the file. First event look at lines 205-252.
Tracker 0 station 1 Plane 1 true momentum is 152.87 (from the x,y and z) components
Tracker 0 station 2 Plane 1 true momentum is 154.37 same calculation.
I am assuming the planes are numbered in the beam direction so this represents a 1.5 MeV
increase in momentum; even if it is a decrease it is far too much for the material
present
Paul K and Adam D
Updated by Dobbs, Adam almost 12 years ago
Chris, just ran the simulation you supplied. The simulation.out file seems to contan plenty of MC hits, but only 0, 1 or occasionally two digits per spill. This seems odd, as you would many per spill from the different, planes, and trackers. Any thoughts?
Ad, Pk
Updated by Dobbs, Adam almost 12 years ago
Chris, Are there any programmes/utilities which allow us to look at the low level digits and /or hits
at a level in between the full analysis and the simple dump of the json data structures. In addition
are there any units tests available?
Pk, Ad
Updated by Rogers, Chris almost 12 years ago
Chris, just ran the simulation you supplied. The simulation.out file seems to contan plenty of MC hits, but only 0, 1 or occasionally two digits per spill. This seems
odd, as you would many per spill from the different, planes, and trackers. Any thoughts?
No idea - this is tracker code but can investigate if you like?
Chris, Are there any programmes/utilities which allow us to look at the low level digits and /or hits
at a level in between the full analysis and the simple dump of the json data structures. In addition
are there any units tests available?
Not right now - what do you want to do? We can do one...
Updated by Rogers, Chris almost 12 years ago
Dobbs, Adam wrote:
Looking at the file. First event look at lines 205-252.
Tracker 0 station 1 Plane 1 true momentum is 152.87 (from the x,y and z) components
Tracker 0 station 2 Plane 1 true momentum is 154.37 same calculation.
I am assuming the planes are numbered in the beam direction so this represents a 1.5 MeV
increase in momentum; even if it is a decrease it is far too much for the material
present
Paul K and Adam D
Tracker 0 Station 2 z = -4850.516721362706 p = 154.37 z = -4648.841575467389 p = 152.87
Tracker 0 Station 1
station 2 is upstream of station 1...
Updated by Kyberd, Paul almost 12 years ago
Chris,
Unit tests ... we ought to have some and I have no desire to reinvent the wheel so before I start thinking about writing them I want to know what is already present.
Adam and I ran the tar file and the analysis job which goes with it that you sent. But since there are no digits we are assuming that you must have run it at the hit level? In which case your plots say nothing about the problem which Summer reported which refers to digit level code. The fact that there is occaisonal digit in the output stream certainly points to a bug. Either the digits are switched on or not.
Your offer to investigate the problem is appreciated, but since I have taken responsibility for the tracker part of the MC I'd rather book some time in the new year for a tutorial on the way the system works. Our current problem is that without a reliable source of MC tracks the tracker group can't develop a track finder/fitter.
Updated by Rogers, Chris almost 12 years ago
Adam and I ran the tar file and the analysis job which goes with it that you sent. But since there are no digits we are assuming that you must have run it at the hit
level? In which case your plots say nothing about the problem which Summer reported which refers to digit level code. The fact that there is occaisonal digit in the
output stream certainly points to a bug. Either the digits are switched on or not.
That's correct. In conversation I understood folks were concerned with the Geant4 part of the simulation, which is my responsibility - so that's what I looked at.
Unit tests... There is- src/map/MapCppTrackerDigitization/test_MapCppTrackerDigitization.py which tests the digitization code.
- tests/cpp_unit/DetModel/ which tests the tracker Geant4 code at unit level (geometry set-up etc)
Updated by Tunnell, Christopher almost 12 years ago
I'd trust the tracker geometry and energy deposited in fibres, but nothing else. MapCppSimulation gives you energy deposited in volumes, which should be trusted if you know the tracker and magnets in the right place. Which they aren't (at least last time I checked).
The MC detector side is a bit light at the moment (TOFs included).
Updated by Kyberd, Paul almost 12 years ago
Chris,
Do you have any tests which can be run stand alone which confirm the statements about tracker geometry
and energy deposition? It would be useful when we start imporvinging the simulation
Updated by Rogers, Chris almost 12 years ago
We used to have tests for energy deposition model in G4MICE - I haven't moved them across yet. I haven't done anything which I would expect to change the energy deposition model, but accidents do happen.
Tracker geometry is not tested. Perhaps the first thing to do for tracker monte carlo?
Updated by Rogers, Chris about 11 years ago
- Status changed from Open to Rejected
I think no longer relevant?