asalzburger / sms2021-tra-tra Goto Github PK
View Code? Open in Web Editor NEWRepository for SummerStudent 2021 project to learn a (conformal) TRAnsform for TRAcks
Repository for SummerStudent 2021 project to learn a (conformal) TRAnsform for TRAcks
Input features: max number of hits times (x,y,z), N hidden layers, output node: [0,1] probability, [0,1] contamination
Take first NN with only [0,1] probability output, classify every hit in the bin to be on/off.
Best architecture would be an RNN.
Let's assume your HT brings hight quality track candidates (start with optimal):
Construct a NN that predict the particle properties of the particle that created the hits.
Input would be:
Maximum size x (x,y,z) -> Some hidden layers -> 6 variables: (x0,y0,z0),(px0,py0,pz0).
In data/pdg13-n25-0.5to10GeV-0.5eta
there are more complicated input files. The simulation is now done with
Info: curvature, magnetic field, particle mass.
As soon as you have installed the ACTS project, you can produce your first data set:
./ActsExampleParticleGun -n100 --gen-nparticles 25 --gen-mom-gev 0.25:10. --gen-mom-transverse true --gen-eta -0.5:0.5 --output-csv
./ActsExampleFatrasDD4hep --dd4hep-input=../../acts/thirdparty/OpenDataDetector/xml/OpenDataDetector.xml --output-csv --bf-constant-tesla 0:0:2 --input-dir="./"
They are used to:
With the command written above you are producing 100 events (-n100
) with 25 particles each (--gen-nparticles 25
) [by default you simulate single muons with pdgId=13] uniformly distributed in eta between (-0.5, 0.5) (--gen-eta -0.5:0.5
). You set the transverse momentum (--gen-mom-transverse true
) to be uniformly distributed between 250 MeV and 10 GeV (--gen-mom-gev 0.25:10.
). The output files will be in cvs format (--output-csv
).
For the detector simulation we use the OpenDataDetector (ODD) (--dd4hep-input=../../acts/thirdparty/OpenDataDetector/xml/OpenDataDetector.xml
) assuming an homogeneous axial magnetic field of 2T (--bf-constant-tesla 0:0:2
). The directory of the input files is also specified (--input-dir="./"
) as well as the format of the output files (--output-csv
).
Define the transformation to move from the (x,y) parameter space to the (phi_0,q/p_T) feature space. A bit of math is posted below.
Plot the tracks in the (phi_0,q/p_T) and produce the binned version of the accumulation histogram, where the crossing point can be evaluated.
About the efficiency plots:
In data/pdg13-n1-1GeV-0.5eta
there are 100 single muon (PDG code 13
) events simulated in a test detector.
The simulation was done with:
(0,0,1)
|eta| < 0.5
to stay within the barrel region (eta
is called pseudo-rapidity)Investigate the hits
and particle content:
hits
in x/y plane (transverse view)hits
in r/z plane (longitudinal view)Look / research the concept of a Hough
transform.
List of datasets to be produced:
This needs a material map file odd-material-map.root
. To activate this, one needs to specify the material input file in the Fatras
simulation, by adding the following program options:"
--mat-input-type=file --mat-input-file=odd-material-map.root"
This needs a magnetic field map odd-bfield.root
. To use this, one needs to add the following commands to the Fatras
configuration:
--bf-map-file=odd-bfield.root
These two options can also be done together of course (which presents the worst case).
The files are part of a PR into the ODD detector (not merged yet):
https://github.com/acts-project/OpenDataDetector/pulls
Accessing them needs git large file system (git-lfs)
support.
As we hadn't talked about particle type, we should do that as well:
Some actions:
If we want to see the effects of magnetic field / material on muons themselves:
You have successfully validated the Hough transform in (phi,q/p_T) and built up combinations of the information from the two feature spaces. It is time now to study the effect of detector material and non-homogeneous magnetic field.
Considering the results from #12 and #16, we can use the approximated transformation and use combination 1.
Evaluate the efficiency as a function of pT and eta for the three cases: perfect scenario, w/ material effects and w/ non-homogeneous magnetic field.
Evaluate the fake rate and the duplicate rate, if possible as a function of eta and pT as well.
It would be also nice to see how these effects pollute the Hough transform and how the hot spots look like in the feature space. This would require some gymnastic with the random number generator to be able to generate the same particles for the three configurations considered.
- Evaluate the bin of the phi (or q/pT) for the true particle and pick the bin center
- Use the phi (or q/pT) bin center from the true particle as hit values and make the Hough space accumulation plot. This will allow to understand how the bins spread for one variable if we fix the other one.
Plot the residual for phi and q/pT (comparing the value of the reconstructed found track (nhits>8, 9, 10) and the true particle)
Compare with bin width used
For q/p_T the bin size in the Hough space is not optimal. Let's try to change it and see how the counts vs q/pT residual changes.
Same as above, shown using nhits>8, 9, 10 when selecting the reconstructed tracks
Once we have defined a better q/p_T bin size and observed how the residual change as a function of the number of hits in the bin used to select the reco track we need to look at efficiency and duplicate rate as a function of the number of hits.
--> Look at the other issue where combining the longitudinal and transverse HTs ;)
Implement a first straight line based hough transform, e.g. from sci-kit learn:
https://scikit-image.org/docs/0.3/auto_examples/plot_hough_transform.html
Further refinements:
(1) Truth based efficiency function
Given a set of hits found [f]
, look up how many of the hits are actually from the same particle using the truth association.
I.e. every hit in the production file has an identifier, which particle produced it.
Updates:
(2) So far, you are taking the 25 best tracks per event, because you know (falsely) that there are 25 particles produced.
To overcome this, we use selection criteria without looking at truth information:
Andreas was right, dictionaries are not for big data. I implemented (literally) everything using arrays. Now the results are incredible. For npileup = 200
, the runtime of the efficiency rate dropped from 1-2 years to 1 minute. Amazing. Here are the results:
The Efficiency looks nice. The duplicate/fake rates are an issue. The purification algorithm takes a lot to compute, since basically it runs the rz Hough Transform for each bin. I may need to think of a smarter solution to overcome this problem. Maybe NNs are the way to go, so I will invest most of my time there.
The geometry_id
carries the volume
, layer
and sensitive
information via bit masks:
// (2^8)-1 = 255 volumes
static constexpr Value kVolumeMask = 0xff00000000000000;
// (2^8)-1 = 255 boundaries
static constexpr Value kBoundaryMask = 0x00ff000000000000;
// (2^12)-1 = 4096 layers
static constexpr Value kLayerMask = 0x0000fff000000000;
// (2^8)-1 = 255 approach surfaces
static constexpr Value kApproachMask = 0x0000000ff0000000;
// (2^28)-1 sensitive surfaces
static constexpr Value kSensitiveMask = 0x000000000fffffff;
Prepare functions to decode this
Implement baseline methods for removing duplicate tracks from the Hough Transform output.
For both baseline approaches implemented, the efficiency drops as well with the duplicate-fake rates. This happens because tracks that are not duplicates are considered so, thus they are removed. To solve this, we must fine tune a bit further those baseline algorithms:
Implement a more profound (yet somewhat deterministic) method of filtering out duplicate tracks. Maybe build on top of the baseline and also use geometries?
Implement a Machine Learning approach to duplicate removal. For this:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.