Embedded Files
CMS Hadron Calorimeter Scintillator Project
References:
[1] http://pdg.lbl.gov/2011/reviews/rpp2011-rev-passage-particles-matter.pdf
[2] https://docs.google.com/file/d/0B_Ce2ncoxFYka2V5US1MR2xvbXM/
[3] http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04437293&tag=1
[4] https://cds.cern.ch/record/2020886/files/LHCC-P-008.pdf
[5] https://sites.google.com/a/physics.umd.edu/physhonr268n/tutorials/geant4tutorial
[6] https://github.com/ZishuoYang/GEANT4-ScintillatorTile/blob/master/CMS_DN2015_009.pdf
[7] https://physicsopenlab.org/2016/02/07/energy-resolution-in-gamma-spectrometry/
[8] https://github.com/saraheno/AlanHorstGEANTTile
[9] http://geant4.cern.ch/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/GettingStarted/index.html
[10] http://geant4.cern.ch/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/Detector/geometry.html
[11] https://www.ge.infn.it/geant4/training/ptb_2009/geometry_lp.pdf
[12] http://nngroup.physics.sunysb.edu/captain/reference/master/detSim/dox/detSimGPS.html
[13] http://hypernews.slac.stanford.edu/HyperNews/geant4/get/docsexamples/263.html
1/31/18
Met with Professor Eno and Belloni today along with the other students working with them. We discussed possible projects for us to work on, and we decided the most suitable one would be a software development project. Based on the references she provided, I assume we will be working with GEANT4. Some part of the CMS Calorimeter is nearing its death, and our task is to help develop better software for the replacement piece(?). She has given us some references to read before our next meeting, and has asked us to bring some slides on what we read, along with questions about things we didn't understand. We plan to meet every Wednesday at 2, and possibly present some of our work at conference meetings later on.
2/7/18
We met with Professor Eno again, and discussed the references she sent us. She prepared a set of slides going into further detail on plastic scintillators, specifically how they work, how radiation damages them, and what we were being tasked with. She also had us present what we learned from the references, although the presentation was cut short due to time. The first reference is about particles and their interactions with stopping materials, providing equations that describe cross-sections and energy loss in said interactions.The second reference was an excerpt from a book, with the specific passages she marked discussing different types of scintillators (crystal, liquid, plastic, etc.) and what makes a good scintillator (pi-electron structure). The third reference was a proposal to use SiPMs (silicon photomultipliers) in the CMS detector, since they work well in magnetic fields and have a number of other useful properties. The fourth reference is a design plan for the Phase-II upgrade of the CMS. This plan included diagrams of the different parts of the detectors, and a description of how certain parts are designed/located within the detector. Notes from these references, including diagrams, can be found in the week 2 presentation: HONR269_ Week 2.pptx. For next week, Professor Eno has asked that we follow the tutorial in reference 5 and install GEANT4. Next weeks update will most likely include documentation from attempting to install it.
2/13/18
Professor Eno had us follow this tutorial, while on the cluster:
mkdir junk
cd junk
cp /data/users/eno/StandAlone/PFCal/PFCalEE/g4env.csh .
source g4env.csh
cp -r /data/users/eno/geant4.9.6.p04/examples/basic/B4/B4a .
mkdir B4-build
cd B4-build
cmake -DGeant4_DIR=$G4LIB ../B4a
make
./exampleB4a
/tracking/verbose 1
/run/beamOn 1
exit
After some computer troubles, I was able to follow the tutorial, and install/run GEANT4. The sample code produced the following image:
It also produced a root file which contained various histograms, that I don't quite understand yet, and will ask Professor Eno about. The tutorial also instructed us to look at the code, which I did, although there was a lot to look at, so screenshots of those will not be included here. The code can be found in Professor Eno's directories, listed in the above instructions. I also read reference 6, which Professor Eno sent to us last week. It appears to be a discussion of liquid scintillators. In one of the previous references ([2]), liquid scintillators were mentioned as an alternative to plastic, as they are significantly more radiation hard (showing no observable degradation after 50 Mrad, while plastic does show significant losses). This document expands on that, presenting some research on liquid scintillators, and their efficiency, although this is unlikely to come into play in our project, since we are working with plastic scintillators specifically.
2/14/18
We met with Professor Eno again, and discussed what we did over the week. In particular, we went over the images that GEANT produced, and what the different parts mean (I didn't realize you could rotate the image to see other parts) and how the code worked. We also briefly discussed liquid scintillators, although we didn't go into a lot of detail. She assigned us some more reading from the previous references, and some of the GEANT exercises from the tutorial page. The goal of this exercise seems to be to figure out how to create and analyze data with GEANT, using the example project as a base.
2/21/18
Professor Eno was out this week, so we met with Professor Belloni, and discussed the stuff we read last week. I personally didn't get a whole lot out of the meeting, as the reading was confusing to me, and I couldn't get all of my questions answered. We weren't assigned any new material this week, so I plan to try reading through the material again and make sense of it this time. I attempted the exercise, and while unable to find out how to graph the energy resolution, I was able to change the variables mentioned in the exercise (number of particles, particle type, detector geometry), and produced the following simulation images:
In order, they are: 1000 electrons, 1 pion, copper instead of lead as a stopping material, and double thickness liquid argon. I will also continue this exercise, and try to figure out how to get the energy resolution from GEANT4. Note that in order to run the exercises, the appropriate variables had to be changed (Particles can be found in /B4/src/B4PrimaryGenerator.cc, materials can be found in /B4/src/B4DetectorConstruction.cc), and the program had to be recompiled (Follow the steps in the tutorial, starting with the step "make" in /B4-build). Additionally, before starting, it appears that the source needs to be redefined each time you connect to the cluster, by running "source G4_setup.sh" before doing anything else.
2/28/18
Continuing to work on last weeks material, I went over the technical document again, reference [4], in an attempt to understand it better, which I think I was successful at. Section 1 is a discussion of the LHC and its technical capabilities, as well as a general plan for upgrading/maintaining it going forward, while section 3.5 details a specific upgrade of the calorimeters to high-granularity calorimeters. Additionally, I went back to the GEANT4 exercise, and after some documentation reading, was able to figure out how to add histograms, and change the number of events. As it turns out, the command /run/beamOn 1 from the tutorial isn't just using that 1 as a boolean value, it represents the number of events. So for 1000 events, you would do /run/beamOn 1000. If doing a large number of events, it helps to do /vis/disable, to disable the simulation visualization, as it slows down the process significantly. Below are some of the histograms generated using the default example setup. I'll include more about histograms next week, after I've had time to work with them more.
3/7/18
Continued working on GEANT exercise, focusing on understanding energy resolution. I did some research on my own and found reference 7. The takeaway from it is that energy resolution is measured as the full width at half maximum of a Gaussian distribution fitted to a histogram of the detected particle energies.
The value is approximated as 2.35*sigma, where sigma is the standard deviation of the distribution. I was able to get this to work with the default run settings (1 GeV electrons), but when trying to fit the distribution to the other historgrams, I ended up with weird functions that did not fit the data very well, so I will continue to work on that. In order to access the histogram, you have to give it a proper name in the code (when defining it, the name is the first term in the function). When in ROOT, run (Name of the histogram)->Draw() to draw it, then (Name)->Fit("gaus") to fit it to a Gaussian. It may be better to use (Name)->FitPanel(), since that seems to provide more options to control the fit. If you don't know the name of the histogram, you can do (Name of current TFile)->ls() to get a list all of the histograms in the file.
In the above picture, sigma is given as about 1.58%, multiply by 2.35 to get a resolution of 3.71%.
We also went over how to access the actual histogram structures (as mentioned in the previous paragraph), allowing for redirecting the output of the GEANT simulations to other code for analyzing/using, as well as using ntuples to access information without having to rerun code. Our assignment for this week is to continue with the GEANT exercise, as well as start the ROOT exercise so that we learn how to manipulate/use the output of the GEANT runs for other things.
3/14/18
We continued working on GEANT and ROOT this week, with more the focus shifting to ROOT and analyzing the data from the simulation. We also worked out the bugs with getting things running with Condor. I came in with a list of questions, and found out a couple things about GEANT/ROOT which are worth noting. The detector geometry is complex, and cannot be changed on the command line like the particle type/energy, which was expected but still important to note. Trying to automate/write flexible code to check several root files at once is not easily possible, and for the sake of this project, it is mostly better to just hardcode opening the files. For the pion simulation, the detector thickness needs to be increased for the data to be useful, otherwise the pions just pass right through and the resulting data isn't able to be fitted to a nice looking Gaussian curve. The goal for this week is to look at more of the examples that Professor Eno provided us, and use those to figure out how to automate more of the simulation/analyzing process. I have included an image of the 1 GeV pi+ simulation and the 1 GeV e- simulation histograms, as an example of how the pion data is much less useful with the current detector settings I have.
3/14/18
Not much to say, very few changes made to the code over spring break. Still trying to get histograms to look more Gaussian in distribution.
3/28/18
After spring break, we continued attempting to automate the simulation process, as well as work on producing better (more Gaussian-shaped) histograms for the pion simulations by increasing the thickness of the detector. To do this, in the detector geometry file, modify the existing values for length and recompile with 'make'. Increasing the detector thickness by 3x the original example provided better results(as shown below) for pions but takes longer to simulate.
Since it is getting late in the semester, and not much more can be gotten out of the exercise, we are moving on to the next part of the project. Professor Eno linked us to a git repository containing advanced GEANT code ([8]), and asked us to try and understand it/figure out what it does for next week. I could not get it to run yet, as I could not find the main executable, and running make results in an error, but the repository does contain some root files with histograms, which I will work on analyzing this week.
4/4/18
Professor Eno found some errors in the git repository files and fixed them for us, thereby fixing the errors and allowing us to run the program. I re-cloned the files (git clone "repository url"), and followed the README contained within them:
git clone https://github.com/saraheno/AlanHorstGEANTTile.git
cd AlanHostGEANTTile
source g4env.csh
mkdir build
cd build
cmake -DWITH_GEANT4_UIVIS=ON -DGeant4_DIR=$G4LIB ../UMDSRDGEStudy
make
cp -r ../UMDSRDGEStudy-utils/* .
./LYSim at the prompt. do the commands in photontest.mac
After looking at the code in [8], and getting it to successfully run, it appears to be intended for testing the detection of particles by a scintillator, with the intention of studying the light output/collection capabilities of this specific type of tile, which according to the description is based on a commercial scintillator called the EJ-200. Below is a picture of the tile in the simulator, both before and and after the simulation has been run.
This particular simulation uses optical photons, and records how many are detected and their energies. The following histograms shows the number that were detected (look at the mean), and the energies at which they were detected. Notice that the mean of the first histogram corresponds to the number of entries in the second histogram.
This week, we are going to attempt to manipulate the geometry of this detector, so we understand how it works when it comes time to run our own tests. A quick look at the detector geometry file shows that is significantly longer and more complex than the one used in the exercise example, so it may take a bit more effort to understand.
4/11/18
After digging though the detector geometry code in LYSimDetectorConstruction.cc, I managed to figure out that most of the things set in the first part of the file are actually overwritten when certain functions in main were called, which was why changing them in the detector construction did nothing. After discovering that, I was able to successfully change the detector construction from a tile to a rod, as shown below, by running ./LYSim 1, instead of just ./LYSim:
Additionally, after asking Professor Eno about certain parts of the code, she has informed us that a large portion of the code is extraneous, and the important part is the actual definition/placement of the geometry, not the various other math being done throughout the file. She has asked to write our detector geometry code from scratch, with us starting on an empty file, and only including necessary code so as to reduce the clutter and clean up the file somewhat. We are continuing with building the geometry of proposed scintillator, which is a rectangular shape with a small hemispherical dimple on it. I had to do some research to figure out how detector geometry worked and how a dimple like that would be possible, and I found references [9], [10], and [11]. In them is a description of how to define geometry shapes, assign materials to them, and place them in the world. In particular, they detail functions which allow for boolean math on shapes, which would allow for a sphere shape to be subtracted from a base rectangle, creating the shape that we are trying to make. My goal for next week is to create the proposed scintillator shape, and possibly run some some tests on it.
4/18/18
This week, we worked on getting the actual geometry of the tile set up. Below are screenshots of the changes to the geometry in the code. Note that in the tile code, the new dimpledTile object must replace the original tile object for logicTile input, which isn't included in these screenshots. Professor Eno couldn't meet with us, since she was at CERN this week, but she did email someone about the dimensions of the tile, which were set in the code. The photodetector is 3mm x 3mm, while the tile itself is 3cm x 3cm. The dimple is a circle with a radius of 6mm, and a depth of 1.6mm. I am unsure about how thick the tile and photodetector were supposed to be, so I made an estimate, which I will ask Professor Eno about next meeting. I added the new geometry as a separate option from the previous 2, able to be accessed by running ./LYSim 2.
Below is are images of the tile with 0, 1, and 100 optical photon simulations. Note that the photons come from the 'top' of the tile (positive y direction), and hit the 'bottom' of the tile, before bouncing off in random directions. Unfortunately, as it is right now, none of the photons hit the detector, and the efficiency of the tile is 0. The yellow 'X' shape is presumably how GEANT handles modifying the faces in the middle of the tile, and has no impact on the simulation. Additionally, the paths of the photons are green, as opposed to the red paths in the previous simulation. This is due to the removal of the wavelength shifting fiber, which was set to change the color of the paths of any photon that was shifted by it. As this tile has no need for a fiber like that, the paths of the particles is green. This week, the plan is to figure out why no photons are detected, and also modify the particle generation to be randomized, instead of coming from the same direction/position every time.
4/25/18
Following up from last week, the goal was to figure out why the efficiency was 0. After conferring with Professor Eno, I found out that the tile was coated in Tyvek, a reflecting material, which prevented the photons from being able to leave the tile. I replaced the following block of code with just the section about wrapping it in air (the statement in the else block):
In addition, in order to generate the particles with random directions, I found reference [11], and modified the running macro to be:
This generates particles at (0, 0, 0) which is the center of the tile, and are randomly distributed in all directions evenly (/gps/ang/type iso does this). Running this simulation now results in an efficiency of around 12%, which is a significant improvement. The simulation looks like this (for 5 events, so the lines can be clearly seen):
The goals for the next week involve finding a way to wrap all of the tile in Tyvek except the dimple, so particles will only be able to leave through there, and generating the particles in random positions, seeing which position(s) yield the highest efficiency. I found reference [13], which seems to be aiming to do something similar to what I want for the wrapping, so I'll be looking into that, although I may not get to it. Following that, the next step would be to generate particles at random positions on the tile, and figure out which position yields the highest efficiency. Since the semester is nearing its end, and I have to work on the final paper/presentation/poster, I may end my work here. I will comment and upload my code to git for the next students to use. Overall, we got decently far, setting up the tile geometry that we were working towards, and successfully running simulations with it. We probably could have gotten farther if we hadn't spent as much time on the exercise, but it was necessary to our understanding of how GEANT4 worked.
5/2/18
This will most likely be my second to last logbook entry, as we near the completion of the poster/paper. I have been able to successfully able to wrap the tile in Tyvek, by placing it (and the photodetector) in a mother volume of air, and setting the borders between that volume and the tile to be Tyvek. I also cut out the dimple and a little bit above the dimple from the mother volume, so that the dimple is not bordering the mother volume, and therefore not wrapped in Tyvek. It gives an overlap error that I am not sure about, since it doesn't give the overlap error when I don't cut out that space, so I'm going to ignore it for now and ask Professor Eno about it. Below is the wrapped tile (orange is the mother volume), and the relevant code.
Additionally, I booked 2d histograms that keep track of all of the random particle generation spots(X,Y), and all of the spots where the particle was detected using the following code:
In the run action file:
man->CreateH2("h6", "Generation Position(X, Y)",
100,-1.5*cm,1.5*cm,
100,-1.5*cm,1.5*cm,
"mm", "mm");
man->CreateH2("h7", "Generation Position(X, Y) for Detected Photons",
100,-1.5*cm,1.5*cm,
100,-1.5*cm,1.5*cm,
"mm", "mm");
man->SetH2XAxisTitle(1, "X Position");
man->SetH2YAxisTitle(1, "Y Position");
man->SetH2XAxisTitle(2, "X Position");
man->SetH2YAxisTitle(2, "Y Position");
And then in the Analysis file:
G4PrimaryVertex* ivtx = anEvent->GetPrimaryVertex();
G4double xPos = ivtx->GetX0();
G4double yPos = ivtx->GetY0();
man->FillH2(1, xPos, yPos);
if(EventPhotonCount == 1){
man->FillH2(2, xPos, yPos);
}
Professor Eno provided us root code to analyze the 2d histograms and create a heat map from them, which I have attached to this page. Our goal for next week (and possibly our last one) is to create heat maps for several different dimple radii, and compare them to see which one results in the most even efficiency over all of the tile.
5/10/18
This week, we met with Professor Eno in order to finish our poster. For the poster, I used the divide2.C code to generate efficiency heat maps for photon generation position versus efficiency for several different dimple radii, ranging from 4mm to 14mm. After modifying some geometry errors that I made, I was able to get rid of the overlap error, so now the simulation is fully setup and cuts out only the non-physical events as intended, Included below is the run macro and the heat maps for the 6mm and 14mm radius dimples respectively. I ran 1 million events for each tile geometry, in order to minimize error.
/vis/disable
/tracking/verbose 0
/gps/particle opticalphoton
/gps/energy 2.95 eV
/gps/position 0 0 0 cm
/gps/pos/type Volume
/gps/pos/shape Para
/gps/pos/halfx 1.5 cm
/gps/pos/halfy 1.5 cm
/gps/pos/halfz 2 mm
/gps/ang/type iso
/LYSim/SetInducedAbsLength 74.95 cm
/LYSim/Update
/run/beamOn 1000000
The lines in the macro referring to half length and volume are setting the generation position to be randomly generated across the box shape of the tile. Since this would also generate particle in the space cut out by the dimple, I also had to make some changes to the histograms. In the analysis file, I added an conditional statement to cut out unwanted photons that would be generated in the dimple location (non-physical events):
G4PrimaryVertex* ivtx = anEvent->GetPrimaryVertex();
G4double xPos = ivtx->GetX0();
G4double yPos = ivtx->GetY0();
G4double zPos = ivtx->GetZ0();
G4double dimpleRadius = 6*mm;
G4double dimpleDepth = 1.6*mm;
G4double tileZLength = 4*mm;
if( (pow(xPos/dimpleRadius, 2) + pow(yPos/dimpleRadius, 2) + pow(zPos+(tileZLength/2), 2)/pow(dimpleDepth, 2)) >= 1){
man->FillH2(1, xPos, yPos); //X and Y of generated particles
if(EventPhotonCount == 1){
man->FillH2(2, xPos, yPos); //X and Y of detected particles
}
}
As the dimple radius increases, the efficiency across the tile appears to increase, at the cost of losing efficiency in the space below the dimple. At first we thought this may have been an error in the simulation set up, but after talking with Professor Eno, we found out that this result has been observed before in physical tiles, so it is not completely unreasonable. As mentioned before, this is the last work I'll be able to do on the project, but the next students to work on it will need to vary the dimple depth, radius, and location in order to find the optimal tile geometry with uniform efficiency across the tile.
Page updated
Report abuse