PropagatedCharge with 0 charge using TransientPropagation

[kirstyap]

Hello,

I have been trying to use the TransientPropagation module and PulseTransfer module along with an electric field and weighting potential simulated in TCAD to more accurately simulate the response of a hybrid pixel detector. The device I’m trying to simulate has 110um pitch, 300um p-in-n device, so hole-collecting, with a bias of 90V applied.

I’ve previously used the GenericPropagation and PulseTransfer modules with the electric field simulated in TCAD. However, using the TransientPropgation with the simulated weighting potential causes a segmentation fault when trying to write the output of the simulation to a root file using the ROOTObjectWriter module. It specifically fails when trying to write PropgatedCharge objects to the ROOT file (writing PixelCharge and DepositedCharge objects doesn’t produce any problems). I’ve included a copy of the simulation output and fault below. The key part is this part:

“Fatal in TBufferFile::AutoExpand: Request to expand to a negative size, likely due to an integer overflow: 0x80020c8e for a max of 0x7ffffffe.
aborting"

Using the TextWriter module in place of the ROOTObjectWriter module, it appears that the charge of all PropagatedCharge objects is zero (although all the DepositedCharge objects have non-zero charge). Given the error message mentions a request to “expand to a negative size”, it seems likely that this relates to the cause of the segmentation fault, but I can’t see why the PropgatedCharge objects would all have zero charge. I am not simulating any kind of recombination of the charge carriers at this stage. The fact the PropagatedCharge objects all have zero charge explains why all PixelCharge objects have zero charge associated with them.

I can’t see anything obviously wrong with my configuration or the electric field and weighting potentials. I have included plots of the weighting potential and electric field, along with the configuration files and screenshots of the TextWriter output showing the non-zero deposited charge objects and the zero-charge PropagatedCharge and PixelCharge objects below.

For reference, I’m running this on CentOS7 and the details of my configuration are as below:

Allpix Squared version v2.1.1-tar
built on 2022-02-22, 12:06:18 UTC
using Boost.Random 1.78.0
ROOT 6.22/02
Geant4 1062

It’s perhaps worth noting that Geant4 build I’m using does not have multi-threading enabled, and so neither does Allpix Squared, though I don’t see why that would be an issue.

If anybody can offer any help or advice, then it would be greatly appreciated!

Many thanks,
Kirsty

[Medipix_60keV_300um_110um_TransientPropagationTest.conf|attachment]
(upload://rSguupafuKfh8RvfiqXSEeKKAne.conf) (1.4 KB)
medipix3.conf (887 Bytes)
Medipix3_Detector.conf (100 Bytes)

[pschutze]

Hi @kirstyap ,

thanks for reporting this! I would assume we have a mixture of two issues here: one is the fact that no signal is induced at your electrodes, the second one is that we do not catch this error correctly on the framework side. The latter is on us and we’ll try to hunt this down. Thanks for the elaborated report, this will help us!

For the first issue: your configuration files were not uploaded correctly, could you maybe fix that? It will help us track down the issue. I assume you are not allowed to share electric field and weighting potential as well?

Cheers
Paul

[kirstyap]

Hi @pschutze, thanks for responding so quickly!

Sorry about the main config file not uploading properly. I’ve tried again below. I wasn’t originally able to upload the weighting potential and electric fields, but I’ve changed the file extension from ‘apf’ to ‘conf’ to get round this.

The fact that nobody else seems to have reported this issue suggests I have made a mistake with my configuration somewhere, I’m afraid I just can’t see it.

Let me know if there’s anything else I can do to investigate on my end or any other details you need from me.

Many thanks,
Kirsty

90V_110um_300um_ElectricField.conf (22.9 MB)
110um_300um_WeightingPotential.conf (7.6 MB)

Medipix_60keV_300um_110um_TransientPropagationTest.conf (1.4 KB)

[pschutze]

Hi @kirstyap ,

I did get a killed process now for your configuration. I’ll keep digging.

Could it be that the issue of having 0 e of induced charge is due to the fact, that you have a negligible electric field in the top 40 um of your sensor, but the weighting potential is almost negligible elsewhere? I’m also wondering whether the weighting potential shouldn’t be normalised for the results to make sense? @simonspa could you maybe comment?

From using GenericPropagation I can see this behaviour here, which looks a bit odd

[pschutze]

Quick note: I tried with a weighting potential that is > 1e-9 (rather ~ 1), and the result looks at least a bit more promising, there’s now induced charge.

[simonspa]

Hi @kirstyap

I also took a look, here is my input

• I agree with @pschutze your weighting potential needs to be normalized to go from 0 to 1. I have done that for you, here is the updated file:
  110um_300um_WeightingPotential_unit.apf (7.6 MB)
  (probably some issue with unit interpretation when converting I would guess - also thanks for noting that apf doesn’t work on the forum, I have changed the settings now!)

• Your simulation time is quite long with 2us - do you expect a signal contribution that late? I thought the peaking time of the Medipix3 amplifier was significantly shorter, O(100ns) or so. Shortening this to let’s say 500ns would decrease the simulation time. Depending on the purity of your silicon sensor material, charge carriers might recombine even in that time frame.

• The main problem however seems to be what @pschutze mentioned already - your electric field and the weighting potential do not really fit together. You have a strong drift upwards until your charge carriers reach that zero-field region, where they start diffusing around. If you look at the pulses created by the transport code, you see that you actually get induced charge, but it will decrease again as charge carriers diffuse back and forth in a non-zero weighting potential, effectively reducing your overall “seen” charge. An example here:

  

  Here, I would expect that curve to just keep growing, eventually flattening out as there are no more charge carriers to transport.

• As for the error message, I still have to reproduce it - but I’m on it

Does this help you a bit?

All the best,
Simon

[kirstyap]

Thank you @pschutze and @simonspa for looking into this so thoroughly so quickly! This is very helpful. I obviously need to go review what’s happening in my TCAD simulation as there’s something not right with my electric field that I hadn’t previously caught. I have a few questions just to clarify things.

your weighting potential needs to be normalized to go from 0 to 1

The weighting potential definitely goes from 0 to 1 before I convert it to the apf format, is there a way for me to avoid this problem when performing the conversion? Using ‘V’ for the observable units parameter in the conversion config file resulted in a potential that scaled between 0 and 1e-6, which I thought was because the default units were MV.

I should say that I’ve realised that the potential I uploaded was the result of using ‘MV’ for the units in the config file. I had played about with the units in the config file to try to get the potential to scale between 0 and 1 but couldn’t get it to work, so in the end took the original result to be correct in light of the framework’s default units. I’m guessing the ‘M’ is being interpreted as ‘milli’ rather than ‘mega’ in the case of the potential I uploaded. (I still got the same segmentation fault using the original weighting potential with a maximum of 1e-6V, probably for much the same reason, though I apologise for the confusion.)

Also, thank you for renormalising the weighting potential I uploaded!

also thanks for noting that apf doesn’t work on the forum

It’s also not possible to upload .txt files, which is why I originally posted the simulation output and TextWriter output as screenshots. I don’t know if that’s also a setting that it makes sense to change?

Your simulation time is quite long with 2us - do you expect a signal contribution that late?

No, not really, again this was a parameter that I changed as I tried to figure out what was going wrong and should have said so.

Lastly, one thing I noticed looking at the TextWriterOutput is that the position of the PixelCharge objects is -150um. My understanding is that the pixel implants should be regarded as being on the positive side of the sensor, which I would have thought would be the place to think of the PixelCharge objects as being. Given my geometry that would be +150um. Have I misunderstood something or is there a reason that the PixelCharge objects are thought of as being on the backside of the sensor?

Many thanks again!
Kirsty

[pschutze]

Hi @kirstyap ,

as you played around with the units a bit: did you also try to set no unit at all? So to remove the observable_units parameter. The Weighting Potential doesn’t really have units, so in my understanding of the code if you don’t set units, there’ll also not be any manipulation. You have the field now, but of course it would be good to sort this out

About the PixelCharge issue: this was a bug in the version you are using. In the latest master this is fixed, but not yet in the tagged releases. Now it is defined as (x,y,0). Before, due to a bug this was shifted to the bottom surface of the sensor. It should however not bother you, you can simply ignore this z coordinate, as you now know it doesn’t mean there’s a problem in the simulation.

Also, now you should be able to upload pretty much any file to the forum, @simonspa fixed that.

Cheers
Paul

PS: @simonspa claims you can’t remove the observable_units, but you can set it to observable_units=1

[kirstyap]

Hi @pschutze,

Thanks for clarifying about the PixelCharge issue. I was worried I was getting confused as to the framework conventions for the positive and negative directions.

I’ve tried setting the observable_units parameter of the Mesh Converter config file to 1 as you and @simonspa suggest but just get the following error when preparing the data for storage:

Fatal internal error
unit 1 not found
Cannot continue.

Is this a change made with the most recent release (it wasn’t obvious to me that this was the case reading the release notes)?

Many thanks,
Kirsty

[pschutze]

Hi @kirstyap ,

indeed, that does not work, I’m sorry. Can you try observable_units = ""? This supplies an empty string, it definitely runs and should be equivalent to the one we suggested.

Sorry again!
Cheers
Paul

[kirstyap]

Yes, that’s it working now . Many thanks again for all your help!

Cheers,
Kirsty

[pschutze]

Great to hear! Anytime!