Medipix3 Threshold Scan simulations

Simulation / Configuration Questions
1

Hi,

I am trying to simulate a medipix3 detector, and I would really like to be able to simulate a threshold scan to determine energy resolution. I can quite easily extract the counts for one given threshold value, but I am not sure as to the best way to go about simulating multiple thresholds. Do I need to run the simulation many times, changing the threshold each time? Or is there a way to setup the simulation so it will loop through a given range of threshold values.

The other problem I have encountered is that when I set the threshold significantly high enough that there are no counts registered, the output root file contains no ‘pixel_hit’ tree. I imagine this could become an issue when performing analysis. Is there some way to set up my config files so this information is still saved even if no hits are registered in the detector?

I’m also curious as to potential ways I can simulate the different gain modes, as well as charge summing for the medipix3 detector. From what I can see in the medipix3 config file provided with the AllPix build neither the gain modes nor charge summing mode are implemented. If anyone has tried to implement these into their simulations I would love to learn more.

I have attached my simulation files.

Thanks,
Rory

dac_scan.conf (893 Bytes)
detector_geometry.conf (75 Bytes)
medipix3.conf (678 Bytes)

2

Good morning @rory_mcfeely !

I think I have satisfying or sufficient answers for the first two questions, let’s see about number 3…

  1. In my eyes the best way to perform a threshold scan is the following: you run a simulation but end the simulation chain after the transfer module, but use the ROOTObjectWriter to write out PixelCharge objects. Then you can run Allpix Squared over and over only using the ROOTObjectReader reading in the previously stored PixelCharge objects, the digitisation, and optionally the ROOTObjectWriter to store the PixelHit objects and the DetectorHistogrammer for a quick visualisation of the detector output. Like this you do not have to run the full chain several times, which saves a lot of time and makes the front end analyse the same statistical fluctuations.
  2. The reason for this is in the way we select the trees to be stored. Does this also happen if you explicitly use the include parameter to store PixelHit objects? If so, I think the simplest way to deal with this would be to catch the case of a missing pixel_hit tree in the analysis and treat this as “no detector signals present”.
  3. Indeed different readout modes have not been implemented. It would be possible to do so in a separate module a la DigitizationTimepix3 or alike. I know that a few people have been working on such a module, but I’m not aware of whether this feature was part of it. As for the gain modes please have a look at our documentation of the DefaultDigitizer. You can modify the gain function to your likings from the configuration file - I hope this is of help.

Cheers
Paul

3

Hi Paul,

Thanks this was really helpful. After implementing your feedback I have been able to write a script to perform threshold scans for varying energies. I got around the PixelHit issue by checking for an error when trying to access the tree, and manually setting the counts to 0 for this case, but this probably isn’t the most bombproof solution.

I will have a look at implementing charge summing mode shortly.

Rory