Solid GEM Digitization
Contents
Introduction
run 3 (by Zhiwen in 2016)
run 2 (by Rich in 2014)
using GEMC 1.x with GEM geometry at
note from Rich
The scripts and gcards I used are in ~rsholmes/batch on the farm. In particular the makejobs*.py scripts submit the batch jobs. Let me know if you have questions. See the gcards in the directory I mentioned before, ~rsholmes/batch on the farm. GEM geometry from solid_CLEO_PVDIS_gem_sbsgem in the repository. a few questions 1. besides the first gas drift (#5 layer) active, you have a few copper layer also active, why is that? 2. Why the 1st GEM gas (#9 layer) not active? Evaristo said it' can create hits also if energy deposition is large enough? 3. I see each PVDIS GEM only has 15 degree opening and each plane has a rotation angle. Is the rotation angle matches what the hardware will be? Does it have digitization or tracking in any way? For the first couple of questions, that configuration is what libsolgem expects. In particular see TSolEVIOFile::GetGEMData. (I believe that was Seamus's code.) That method takes the hit information from the various layers and combines them to create a description of the hit in the whole chamber, e.g. position and momentum at the entrance and at the exit, etc. It uses the hit information in the copper layers to set the entrance and exit parameters. Energy deposition in #9 layer isn't taken into account. I don't know the reason. Basically the GEM sensitivities were defined for libsolgem and the digitization code uses the libsolgem results, so I used the GEM definition script created for libsolgem. All this was probably inherited from or at least based on the SBS code. Seamus probably could tell you more. For each plane there are 30 sectors, 12° apart, and if I remember right the active area of each is 10° wide. So there are 2° gaps between sectors. The rotation angle offsets are chosen to make these gaps coincide with the peaks of the photon backgrounds (coming through the baffles along the hot edges). There was some discussion of that sometime last year because the original GEM scripts used offsets that weren't appropriate for the BaBar baffles, and in any case they were originally defined to put the electron peak in the middle, not to put the photon peak in the gap. I made the adjustments to put the photons in the gaps. I'm not sure anyone has ever said definitively what the widths of the actual hardware GEMs will be but 10° I guess is a reasonable figure. Digitization is done in a separate processing step after the simulation. I believe the script I used calls the digitization code but the output was erroneous due to database problems. (This is the famous problem where the simulation and digitization geometry parameters come from two places, the Perl script for the simulation and a text file database for the digitization; the parameterization is different for the two and converting one to the other is confusing.) However Ole told me he had a tweaked version of the digitization code he wanted to use anyway so all he wanted from me was the simulation output. If you want to run the digitization code yourself I suggest you ask Ole for his code and database. I don't know if his versions are in the repository or not. The present libsolgem and digitization codes and the digitization database make assumptions about which layers are active and how the planes are divided into segments. So they will require revision in order to work correctly if you change the GEMs in the simulation.
GEM geometry info
PVDIS PlateZ = (157.5,185.5,190,306,315)cm //GEM plane center, GEM plane is ~1cm thick PlateZ = (157.5-1,185.5-1,190-1,306-1,315-1)cm //GEM virtual plane is placed 1cm before GEM plane center Rin = (48,59,65,105,109)cm Rout = (122,143,143,230,237)cm
SIDIS PlateZ = (-175,-150,-119,-68,5,92)cm //GEM plane center, GEM plane is ~1cm thick PlateZ = (-175-1,-150-1,-119-1,-68-1,5-1,92-1)cm //GEM virtual plane is placed 1cm before GEM plane center Rin = (36,21,25,32,42,55)cm Rout = (87,98,112,135,100,123)cm
refer to SoLID coordinate system https://hallaweb.jlab.org/wiki/index.php/Solid_Software#Coordinate_System
run 1 (by Seamus in 2013?)
discussion in 2015/12
from Rich
The digitization code (at least when I last worked with it, which was a long time ago) assumes the GEMs are annular segments: that is, bounded on the inside and outside by arcs centered on the x/y origin, and on the sides by radial line segments. The strips are then parallel to one side or the other. Of course the real GEMs will presumably be trapezoids instead, i.e. bounded on the inside and outside by line segments perpendicular to the center line, but this is maybe too small a correction to be concerned with now.
For SIDIS the geometry is more complicated, because the GEMs are the same as for PVDIS but displaced toward the x/y origin, meaning the sides (and hence the edge strips) no longer are radial.
This again may or may not be important at this stage, but it'll have to be addressed sometime, and may be messy.
Really the digitization code (which started off with rectangular GEMs, and was converted by me to annular segments) should have been / should be written to work with arbitrary quadrilaterals. And of course the simulation should make the GEM segments quadrilaterals too.
from Ole
Evaristo's code seemed to have a couple of bugs and performance problems which I have fixed in libsolgem. The bugs were related to the way random numbers were generated and the hit time offset was handled. I'm not sure if these bugs are present in the SBS code as well, they might have crept in when porting things over to SoLID/libsolgem.
There are still problems with the GEM digitization: the width of the charge distribution at the readout plane is too small overall and asymmetric between the two readout strip directions. I asked Evaristo about this in 2014 and didn't get a convincing answer; it seems like they are just tweaking parameters to fit the experimentally observed charge distribution. That may be good enough for the moment, even if the relevant parameter (the diffusion constant) ends up being unrealistically large.
There is a pulse deconvolution and a hit clustering algorithm in JeffersonLab/TreeSearch (use the "solid" branch!) which work reasonably well. These algorithms may also be present in the SBS code, but the deconvolution algorithm there may have a serious bug. Whatever is on GitHub in JeffersonLab/TreeSearch is the best available code to my knowledge.
BTW, I already gave all this information to Weizhi in 2014. He managed to compile and run libsolgem and TreeSearch, but then decided to ditch everything from TreeSearch and use his own standalone code instead. The TreeSearch code is useful as a skeleton within which one can fairly easily implement a different tracking algorithm without having to redo the whole decoding and hit processing steps.
GEM module's geometry and material
The GEM module construction is borrowed from SBS mc code as described below.
SBS code is at http://www.iss.infn.it/cisbani/atmp/sbs/ft/gemc/code/ (a local copy http://hallaweb.jlab.org/12GeV/SoLID/download/tracking/SBS_code)
Details are at https://jlabsvn.jlab.org/svnroot/solid/solid_gemc2/geometry/gem/
a) Entrance window a.0) Al 5um (approx) a.1) Mylar 20um b) First GAP (do not contribute to the signal) b.0) 70Ar30CO2 3 mm c) Drift Cathode c.0) Kapton 50 um c.1) Copper 5 um d) Second GAP (mainly contributor to the signal) d.0) 70Ar30CO2 3 mm e) GEM0 e.0) Copper 5 um e.1) Kapton 50 um e.2) Copper 5 um f) Third GAP (small contribution to the signal) f.0) 70Ar30CO2 2 mm g) GEM1 g.0) Copper 5 um g.1) Kapton 50 um g.2) Copper 5 um h) Forth GAP (negligible contribution to the signal) h.0) 70Ar30CO2 2 mm i) GEM2 i.0) Copper 5 um i.1) Kapton 50 um i.2) Copper 5 um j) Fifth GAP j.0) 70Ar30CO2 2 mm k) Readout Board k.0) Copper 10 um k.1) Kapton 50 um k.2) G10 120 um + 60 um (assume 60 um glue as G10) m) Sixth GAP m.0) 70Ar30CO2 3 mm n) Closing window n.0) Mylar 20um n.1) Al 5um (approx)
GEM response
As we are not simulating the electric field and avalanche in GEM and we only knows the energy deposition in GEM, the GEM response needs to parameterized in the know the signals on readout strips.
GEM parameters
| current value (COMPASS GEM based) | new value from UVa study | comment | |
|---|---|---|---|
| Ionization energy | 26ev | Parameter used in the digitization ion model. It takes in the energy deposition E of a particle in the GEM gas, and calculate the number of ion based on a Poission distribution with mean value (E/26eV) | |
| Gas drift velocity | 5.5e7 mm/s | How fast the avalanche electrons travel along the z-direction (vertical to GEM surface). We assume this velocity is constant within the GEM detector. | |
| Gas diffusion rate | 45000 mm^2/s | This parameter measures how faster the avalanche electrons produced by an ion spread in the x-y direction. We assume that these avalanche electrons will form a 2D Gaussian distribution as they reach the readout board, whose sigma is given by sqrt(2*D*t) where D is the gas diffusion rate, t is the time it takes for these electrons to reach the readout board. So 3*sqrt(2*D*t) gives roughly the radius of the avalanche area. (However in digitization, might be for simplification, we assume the charges are just uniformly distributed within this area, instead of strictly following a Gaussian PDF) | |
| Charge statistic model | 0 (default) or 1 | Calculate the total charge of the avalanche electrons produced by an ion. In the case of 0, the total charge distribution assumes the exponential distribution with mean value given by gain mean (see below). Otherwise the distribution is assumed to be Gaussian with mean value given by gain mean, and sigma given by gain mean over gain0 (also see below). | |
| Avalanche fiducial band | 10 | Not very related to the hardware. In digitization we consider a fiducial region surrounding the avalanche region. This helps us set up the range for the numerical integration for the total charge of avalanche electrons. This parameter is related to how large this fiducial region needs to be. | |
| Gain mean | 8000 | Parameter used in the charge statistic model | |
| Gain0 | 20 | Parameter used in the charge statistic model | |
| tau0/tau1 | 38.3/129 (ns) | The two parameters for the shaping function of a signal. For functional form please see Frank Simon's thesis on COMPASS GEM page 31. | |
| Trigger offset | 125 ns | Delay time in order to ensure the signal comes at around t=0 | |
| Trigger jitter | 1 ns | Uncertainty in the trigger start time | |
| ADC gain | 1 | ||
| ADC offset | 0 | ||
| ADC bits | 12 | ||
| Pulse noise sigma | 0 | How well we can measure the signal amplitude, currently we assume perfect measurement. Otherwise we will smear the measurement by the Gaussian distribution with sigma given by the pulse noise sigma | |
| Sampling period | 25 ns | standard for APV25 | |
| Zout | 9.19 mm | Distance from the copper layer right above the 3mm gas region to the readout board |
note about threshold
Then I use the approach Evaristo Cisbani used in SBS code as following
the idea is basically the following: 1- a particle that releases energy (at least able to generate a ion-electron pair) in the drift gap (layer 5 in JTrackGEMModel.cc) is assumed to produce a hit in the GEM detector plane and to give a detectable signal. 2- you can also consider deposited energy in the first GEM-GEM gap (the closest to the drift gap, is layer 9 in JTrackGEMModel.cc); in this case the ionized electrons miss the first GEM multiplication however signal could be large enough to produce a detectable hit if the primary ionizations are enough (say at least 5 ion-electron pairs) Therefore, particles that have: Edep>W in drift or Edep>5*W in first GEM-GEM gap provide a hit signal and can be considered as background; W is the effective average energy needed to produce one ion-electron pair (e.g. 26 eV for Argon).
SBS info
Vahe's talk ar 2011 summer HallA Coll meeting http://hallaweb.jlab.org/collab/meeting/2011-summer/talks/day2/GEM_Analysis.pdf
SBS review with a lot info about GEM http://hallaweb.jlab.org/12GeV/SuperBigBite/
SBS GEM low energy photon response study http://hallaweb.jlab.org/12GeV/SuperBigBite/SBS_CDR/Response_TR2.pdf
