Hi everyone, I am a physics undergrad student learning to use allpix-2 for the first time. I want to generate a realistic electron waveform hitting a simple pixel detector, but it seems like all the current is being induced as soon as the particle hits the pixel, with the electron hole pairs just catching up in the following nanoseconds. My geometry is a plate of 9x9 pixels, with size equal to cms detector pixels, and an electron beam of 5MeV being shot from -500um away. Uploaded is the current waveform for a 1MeV particle that i managed to obtain for reference. Desired current would include a thinner, 1ns pulse at a time later than t = 0 ns. I managed to obtain something resembling that through setting the energy to about 100kev, but I need something higher than 1MeV for my project purposes. Can anyone tell me why this behavior occurs and possible workarounds? I can also upload simulation configuration and geometry files if needed. Thank you.
Hi, It is hard to say for me what could be the culprit without the conf files, could you upload here the conf files you are using?
Unfortunately, it won’t let me upload any attachments since I’m a new user but I will link the configuration and detector settings: Conf File, Sensor Conf. I am using a .mac file with these settings to shoot towards the detector. /gps/source/intensity 1
/gps/particle e-
/gps/pos/type Beam
/gps/pos/sigma_x 0 um
/gps/pos/sigma_y 0 um
/gps/pos/centre 0 0 -5 mm
/gps/ene/mono 5 MeV
/gps/direction 0 0 1
I have been experimenting and making changes since the original post as well. It seems that changing the mac file geometry to shoot at about a 30 degree angle produces some promising results, it leads to a much thinner and delayed “spike” a lot more times as opposed to the slow increase from the start. I think I understand why but when I switch back to a 5x5 these results seem to become more rare for some reason. Also, the timing and width of the spike are very inconsistent even with the 15x15 setup, which I think I can attribute to allpix randomness but I’m not sure. The other issue is that shooting at an angle hits multiple pixels which for my purposes is great for later on but I am trying to start with a simpler setup. I just don’t know if it’s a question of it wrong physics understanding or wrong setup on my part. If this is the waveform that it produces when it punches straight through 1 pixel that’s fine but I’ve been led to expect otherwise. Thank you for your time!
Hi
I am no expert, but i think that for a 250 um thick silicon sensor, fully depleted with 50 V of bias a collection time of the order of 10 ns makes sense. The fact that in your case you see such an abrupt spike at t=0 might be cause the 1 Mev electron is hitting the electrode of collection very quickly (either cause its on the same side of the source or cause the time for the electron to traverse 250 um is very small, order of ps if i’m not mistaken) and going through it. along its trajectory it generates electron hole pairs which then have a slower drif time. in the worst case an electron generated as electron hole pair can take 10 ns to cross 250 um in you case, but you will probably have many of them generated very close to the electrode almost at t=0 probably, explaining why you see the abrupt peak there and while using a less energetic electron the peak shifts from t=0. in that case the less energetic electron might deviate even more from a straight line trajectory due to interactions in the silicon, leading to smaller deposits of electron hole pairs close to the electrode, delaying the collection time.
when you tilt at 30 deg, the 1 Mev electron might not pass through the collection electrode maybe and instead exit the detector from the side or something like that depending on if you shift the source and how many pixels you have, delaying the propagation time for the electrode hole pairs to reach the electrode, but the trajectory of the 1Mev electron in the silicon is not a straight line, it deviated due to interactions with the material which explains why in some cases you see the nice results you expect and in others maybe you go back to the original one
Also not sure you need the support in the sensor conf, if not needed explicitly i would just set it to 0 as it might just complicate things and leading to unexpected interactions.
I also usually work with user defined electric and weighting potential, so not sure about that but i think it would still be plausible to see what you are seeing. In the manual it explains how you can also save the electron and holes trajectories during the propagations as a gif or as lines in an image. Maybe you can have a look at that to see if something weird is happening?
Bests
Luca
I have run through a couple more simulations, looking into the line trajectories of the holes as you said but they don’t seem to tell me anything concrete as far as I know, atleast from just a screenshot since moving the image is incredibly slow for me. I also tried shooting a particle from about 1m away, which should produce a hit marker about 3ns later at 5MeV, but I just saw the same waveform as always. The only way this could happen is if allpix starts the timer after the electron has already hit the sensor, perhaps due to thresholds set in the settings, but I would need to read more of the manual to find out if there is a way to change this. I will upload the line trajectories here in case that helps but so far I haven’t found a way to reproduce the expected output reliably in a straight on collision.
Hi @yreina
Not really, it just starts immediately, but there is a (near) constant induced current over more than 2ns. That it starts immediately was rightly pointed out by @luca_tero is likely to the fact that when your initial particle crosses the sensor, some charge carriers are left close to the collection electrode, and - depending on your geometry - one step there might induce a significant fraction of the total charge.
Instead of using a fixed position (with zero sigma) try running a few events with more loose sigma to allow different entry positions.
Also, is there a reason you use a G4 macro instead of the builtin beam model?
/Simon