Feature #1739
MC simulation of StepIV June-July run
Added by Rajaram, Durga over 8 years ago. Updated over 6 years ago.
100%
Description
We want to simulate the runs taken in the June-July 01a/b data-taking period.
Files
| virtual_hits_v_z.pdf (15.3 KB) virtual_hits_v_z.pdf | Bayes, Ryan, 02 September 2015 15:16 | ||
| RelativeSurvival.pdf (16 KB) RelativeSurvival.pdf | Bayes, Ryan, 08 September 2015 11:50 | ||
| beam_momentum_v_z.pdf (32.4 KB) beam_momentum_v_z.pdf | Bayes, Ryan, 08 September 2015 11:50 |
Updated by Rajaram, Durga over 8 years ago
We want to be able to simulate the data-runs from June/July.
There is some pressure from the experiment to get this going as soon as we can.
What do we need to get v1 of the simulations going?
For the field-on runs, there's the separate issue of no cooling channel magnet currents in the CDB.
So, maybe we start with field-off runs while that's being resolved.
- This is now in place, and available from the production CDB -- Ryan, correct me if I'm wrong.
- Adam -- are there things you're waiting to have in the next release?
- The G4BL input files need to be made available from a place the GRID nodes can access.
- The files pointed at in the list at https://micewww.pp.rl.ac.uk/projects/mice/wiki/SimulationMuonBeams do not exist.
- Ryan -- do you have an updated list of the locations? Or have the g4bl files disappeared?
execute_MC
has been tested on the Glasgow cluster (?) but we have not put it through the GRID infrastructure. What do we need?- Note that for each run we want to simulate, we'll have to pass the run-number as an argument/data-card.
- The plan -- outlined in http://micewww.pp.rl.ac.uk/projects/computing-software/wiki/Grid-PC150826 -- was to have the g4bl chunk and the data card in the MCModelNumber table.
- Janusz, Ryan -- does that table actually exist?
- it seems to take ~8s/25evts on my fermi box running MC with a binomial beam.
- Some factors to be gained by converting BeamMaker, MCReconSetup, TOFMCDigi, KLMCDigi to handle ROOT/MAUS::Data
Updated by Rajaram, Durga over 8 years ago
G4BL inputs
Update from Ryan on an email thread
Hi Henry,
The (old) chunks were moved at one point I have replaced them (I had two copies of the things in my directory and I deleted the wrong one).
There are new chunks on the same server. I will update the wiki page with the lists these can be now found at
http://www.ppe.gla.ac.uk/~rbayes/150617_3140_pos/3140_z1m.txt
http://www.ppe.gla.ac.uk/~rbayes/150619_3200_pos/0619_3200.txt
http://www.ppe.gla.ac.uk/~rbayes/150727_3240_pos/3240_z1m.txt
These are effectively larger data sets per chunk (10000 particles at z = 1 m rather than 10000 particles at s=-1m).
The grid access file is outright wrong (and always was). The correct files lists are given in
http://www.ppe.gla.ac.uk/~rbayes/MICE/gridfiles/6200G4BL.txt
http://www.ppe.gla.ac.uk/~rbayes/MICE/gridfiles/3140G4BL.txt
http://www.ppe.gla.ac.uk/~rbayes/MICE/gridfiles/3200G4BL.txt
http://www.ppe.gla.ac.uk/~rbayes/MICE/gridfiles/3240G4BL.txt
And I know that they are the correct file listings because I was able to copy them from the grid myself.
Again, I will replace the versions on MICEmine.
Cheers,
================================
Ryan Bayes
Updated by Bayes, Ryan over 8 years ago
- File virtual_hits_v_z.pdf virtual_hits_v_z.pdf added
I have been testing the simulation of the July half field data (run 7288) for the last few days.
I have been running MAUS v1.0.0 on the glasgow cluster using the execute_MC.py script to facilitate the downloads and simulation in a consistent way. I have uploaded my MCSerialNumber settings to the preproduction configuration database for the purpose of testing. I also uploaded the superconducting magnet currents to the preprod CDB using the currents listed in the elog. The beam line that I have been using is provided by G4beamline in 10000 particle chunks listed in http://www.ppe.gla.ac.uk/~rbayes/150617_3140_pos/3140_z1m.txt. The beam settings downstream of D2 were read directly from the CDB.
The simulation settings that are not manipulated by the execute_MC script are
cdb_cc_download_url="http://preprodcdb.mice.rl.ac.uk"
geometry_download_coolingchannel_tag="half-current-DS-24July2015"
geometry_download_beamline_for_run=7288
geometry_download_by="id"
geometry_download_id=68
I have also used
geometry_download_beamline_tag="3-140+M0"
in place of
geometry_download_beamline_for_run=7288
but the two have the same effect.
So far the results have not been terribly promising. The transmission for this beam is abysmal. I have attached a plot of the number of particles detected by virtual planes placed at 50 cm intervals along the beam line. No particles appear at TOF2 (z=21.152m) despite there being some 3000 particles in TOF1 (z=12.929m). Based on the number of TOF1 and TOF2 events in CDB viewer for run 7288, there should be a drop in rate by a factor of 3 from TOF1 to TOF2.
I assume that there is a bug present somewhere. There is the possibility that the issue is in the G4beamline sample itself as previously generated simulations using the 3pi140 beam with the solenoid fields off have shown anomalously few events in the Trackers. I have asked John to generate more samples of the 3pi140 beam, and I am running simulations using these settings with higher momentum beams to confirm that there is not a problem with transmission due to additional material --- with the G4beamline to MAUS interface point at z=1m the only affect of changing the source beam momentum should be in the focussing behaviour of the beam rather than the transmission or bending.
Updated by Rajaram, Durga over 8 years ago
Did you also simulate a no-field run? Wondering if you see the low transmission rate there as well
Updated by Dobbs, Adam about 8 years ago
Any update on how this is proceeding? Ryan, has been any improvement in the transmission? Thanks...
Updated by Bayes, Ryan about 8 years ago
I have simulated a no field run (7158) with the "current" geometry and I again do not see particles in TOF2 (or at least very few). This test assumed a 3pi200 beam so it is unlikely that the problem in the half field run was due to a peculiarity in the G4 beam line sample. The main observation is that there is an exponential decrease in the number of surviving muons through the DS Tracker suggesting that there is a problem with the materials in the Tracker (maybe I am using heavy air).
I am currently at a loss. I will attempt a simulation with the Tracker volume again returned to helium and I will see if the transmission improves. All other materials and volumes are basically unchanged with respect to previous batch simulations which have seen reasonable particle transmission to TOF2.
Unspoken is the point that the step size has been limited with respect to previous simulations. I could increase the max_step_length and see if there is an increase in transmission but this may be a non-issue as the current default is a 10 cm step length.
Updated by Bayes, Ryan about 8 years ago
- File RelativeSurvival.pdf RelativeSurvival.pdf added
- File beam_momentum_v_z.pdf beam_momentum_v_z.pdf added
I have re-run the simulation with Helium in the trackers. This produced no significant change in the effective survival rate through the channel. I have attached the survival plot normalized to the most populated bin. Note that the DS tracker is between z = 18820 mm and z = 19988 which is precisely where the number of particles decreases significantly. This appears to be related to particles ranging out as the mean particle momentum drops significantly (I have attached this figure as beam_momentum_vz.pdf)
I still think that this is because there is too much material in the beam line somewhere. I do not see anything in the channel that could produce the observed effect, so I am working on the possibility that the Air upstream of the channel has too much stopping power compared to reality. Looking at the definition of air used by GEANT4 there is a 1.3% mass fraction of argon which looks high compared to the composition of air that I have found online. I am investigating the effect of decreasing the density of air on the stopping power according to GEANT4. I hope that I can find a solution quickly.
Updated by Dobbs, Adam about 8 years ago
Thanks for the update Ryan. Couple of questions, how does the survival rates you are seeing compare with real data? I know I always see a significant drop in rate between the trackers, though I have never quantified it. Also, should I hold back on doing a release until this is fixed? Is it something which will need to be fixed CDB side anyway? Thanks...
Updated by Bayes, Ryan about 8 years ago
I am currently exploring the corrections on the CDB side. It is a little difficult to arrange for a similar analysis in the data but I have looked at the CDB for run 7288 and compared the number TOF1 triggers to the TOF2 triggers. The number of triggers drops by a little less than a factor of 3 (110000 at TOF1 versus 40000 at TOF2). Clearly a decrease in particle triggers of several orders of magnitude is wrong.
Updated by Bayes, Ryan about 8 years ago
I found the problem. There was an error in the specification of the downstream magnetic field such that the geometry had to assume that the mis-alignment given was in radians rather than degrees. This effectively steered the beam into the wall of the solenoid bore.
Further inspection of the field off run that I attempted shows that the default solenoid fields were used which would then be effected by the exact same problems.
I will post a correction to the CDB ASAP.
Updated by Dobbs, Adam over 6 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100