Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] FATRAS has trouble simulating electrons with eta between -4 and -1 #1284

Closed
Maury-arty opened this issue Jun 21, 2022 · 11 comments · Fixed by #1288
Closed

[Bug] FATRAS has trouble simulating electrons with eta between -4 and -1 #1284

Maury-arty opened this issue Jun 21, 2022 · 11 comments · Fixed by #1288

Comments

@Maury-arty
Copy link

When given the output of Particle Gun for electrons (uniform distribution of eta from -4 to 4), FATRAS has trouble simulating electrons which have eta between -4 and -1. The output of Particle Gun was manually checked and has a uniform distribution in eta as asked.

Concretely, for some electrons, no hits are generated. Those electrons are all with eta between -4 and -1 (in their initial state).
Also, when plotting the eta distribution of all hits, one can see a depletion for electrons between -4 and -1, whereas this distribution remains uniform for muons.

As can be seen in the spatial plot of all hits, in the case of electrons, there is a lack of hits in the "rear" part of the detector while in the muon case, the whole detector has hits.

This issue also arises when using the ITk geometry, the ATLAS B field, different regions of pT, both signs for particles...

To reproduce the error (I used the (deprecated) executables), with the TrackML geometry and a constant B field:
ActsExampleParticleGun --events=10000 --output-dir=1_particle_gun --output-csv --gen-vertex-xy-std-mm=0.012 --gen-vertex-z-std-mm=50 --gen-eta=-4:4 --gen-eta-uniform --gen-pdg=11 --gen-mom-gev=1:5 --gen-mom-transverse
ActsExampleFatrasGeneric --input-dir=1_particle_gun --output-dir=2_fatras --output-csv --remove-neutral --bf-constant-tesla=0:0:2

Replace --gen-pdg option with 13 for muons (mu-).

spatial_hits_electrons
spatial_hits_muons
fatras_hits_muons_electrons_eta
initial_state_electrons_eta

@paulgessinger
Copy link
Member

paulgessinger commented Jun 21, 2022

@asalzburger suggests disabling different material effects (energy losses) to track down which is the source of the issue. There should be a command line option to steer this.

@andiwand
Copy link
Contributor

removing the material with --mat-input-type=none or turning off EM radiation with --fatras-em-radiation=0 removes the artifacts

I was not able to reproduce this with python yet because I could not get the materials up for the GenericDetector which is used by ActsExampleFatrasGeneric

@andiwand
Copy link
Contributor

after enabling the interaction in python I can see the same artifacts

image

@asalzburger
Copy link
Contributor

Looks like this is a problem of either the material description (should not be), or - more likely - a bug in the energy loss module.

One might have to put some cout's in the energy loss function and see what it means.

@Maury-arty
Copy link
Author

Maury-arty commented Jun 22, 2022

It seems that when disabling the fatras-em-radiation option (=0), we don't get this issue at all.

@andiwand
Copy link
Contributor

apparently slab.thicknessInX0() gets negative for the left side of the detector

@Maury-arty
Copy link
Author

@andiwand Interesting! slab.thicknessInX0() indeed seems to get negative values. Thanks for this hugely useful indication ;)
When I put a simple std::abs for this variable, everything seems to get back in order: no missing hits, all electrons have hits from eta -4 to 4.
I'm currently digging as to why this value could be negative and what is its impact.

@andiwand
Copy link
Contributor

the negative thickness is coming from here: https://github.com/acts-project/acts/blob/main/Fatras/include/ActsFatras/Kernel/detail/SimulationActor.hpp#L168

looks like the surface normal looks in the same direction on the left and right side of the detector. not sure if that is intentional @asalzburger ? I would think that they should all point inwards for example

we could put an abs in the SimulationActor or change the surface normal. any preference?

cc @paulgessinger

@asalzburger
Copy link
Contributor

BUG BUG BUG ALERT!

std::abs should do the trick, great work @andiwand

@andiwand
Copy link
Contributor

#1288

@kodiakhq kodiakhq bot closed this as completed in #1288 Jun 22, 2022
kodiakhq bot pushed a commit that referenced this issue Jun 22, 2022
fix #1284

SimulationActor produces negative MaterialSlab thickness if `normal` and `before` produce an angle > 90°

apply `abs` to avoid negative scaling factors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants