|
|
Line 73: |
Line 73: |
| Xin's comment on 2011/09/21 | | Xin's comment on 2011/09/21 |
| http://hallaweb.jlab.org/12GeV/SoLID/download/tracking/for_Nilanga.pdf | | http://hallaweb.jlab.org/12GeV/SoLID/download/tracking/for_Nilanga.pdf |
− |
| |
− | = 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/
| |
− |
| |
− | <pre>
| |
− | 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)
| |
− | </pre>
| |
− |
| |
− | =GEM response=
| |
− |
| |
− | For background study, I use FLUX bank which records every single hit,
| |
− |
| |
− | The FLUX ID is like 1x00000 where x of 1-6 or 1-4 is for the GEM plane number
| |
− |
| |
− | Then I use the approach Evaristo Cisbani used in SBS code as following
| |
− |
| |
− | <pre>
| |
− | 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).
| |
− | </pre>
| |
− |
| |
− | =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
| |
Here is my recent result for the resolution. Detector material and process noise are included in the GEMC simulation and reconstruction. In the link below, you will find three folders, each corresponds to a detector configuration. In each folder you will find many pdf files, named as:
These show the resolution for each momentum and polar angle bin.
Each folder also has one or two root files, which store the resolution values in a root 2D histogram format. (x and y of the histogram correspond to momentum and theta, and z gives the resolution value, see <configuration>_resolution_2d_histogram.pdf for example)
If you have any question or suggestion, please email me at weizhi.xiong@duke.edu