I have a pixel detector with a large number of pixels (1024x512).
So I Replicate pixel volume along the plane to create a lot of pixel logical volumes.
And I would like to readout info of activated cells using Sensitive Detector assigned to the pixel logical volume.
But my computer’s RAM perhaps cannot comprehend so many Logical volumes…
Are there any better way of simulating tiny granularity detectors without requiring tons of RAM? Or this is the only standart way which you also would use?
If the pixels are all identical, then you should have just one single LV defining it, and then either a large number of placements (separately instantiated PVs) or better, a replicated or parametrized volume for all the pixels. Since the SD is attached to the LV, that shouldn’t fill up memory.
A different approach, if your detector is one large chunk of material where the pixels are electronically driven (individual pads or some such), then you could treat it in G4 as one single volume, with one single SD. In your SD code, you could use the hit coordinates to compute a pixel index, or even do more complex things like share the hit energy between multiple pixels.
I am also constructing a pixel detector, but with wedge-shaped pixels in a disc-like detector. I would like to use the latter method proposed by you. Is there an example code in G4 examples that I could use as a starting point? The closest example to begin with I thought was extended/RE01 where a G4VUserParallelWorld is used to define a Readout geometry for the Calorimeter. Is this the right way to proceed? What purpose does the G4VUserParallelWorld serve?
Thanks in advance.
The parallel world allows you to define your readout volumes without worrying about whether they overlap with the physical volumes you used to build your detector. For instance, you could have sensor pads which are partially below the surface, and partially above the surface, without having to carve out (
G4BooleanSubtraction) divots for all of them.
I don’t use that method in our simulation: our sensor pads are lithographic, and in real life sit on the surface of a germanium or silicon crystal, so I built the geometry that same way.
I don’t know if there’s a specific example which does all this for you. Look for an example that uses replicated or parametrized placements. if you attach the SD to the logical volume that goes into the replication, then you’ll get hits in all of the instances, and the copy number will tell you which one was hit.
This example I am using has a barrel calorimeter (G4Tub) of scintillating material and many thin lead G4Tubs are placed using G4VParametrisation. Later in the readout geometry, a G4Tub of a dummy material is created with the same dimensions as the barrel calorimeter and cells are created by making divisions in phi and z using G4Replica. Later in ConstructSD(), the readout logical cells are passed to SetSensitiveDetector().
I have modified the example to contain six disc-shaped tracking layers using G4VParametrisation. Now within each of these disc layers, I would like to define wedge-like pixel hits. My plan is to use the same approach as in this example for the Calorimeter. However, my worry is that this example has much fewer sectors along kPhiaxis (48) and slices along kZaxis (20), whereas I will have around 2000 times more sectors along kPhiaxis and similarly along the radial direction. Will this fill up all the memory and lead to poor performance or not?
Also, since my tracker layers have been constructed using G4VParametrisation, do I have to define hits individually for each of the disc layers or doing it for one takes care of all (as they all have the same logical volume)? I am sorry if my questions are a bit too naive.
Lots of good questions!
No. That’s what the replicated placements do for you. You only have one single geometry object in memory, with a function tied to it. When the geometry gets built, the function is used to compute all the information about each replica, instead of creating actual placement objects. The voxelized geometry (which is what is used for tracking) will be the same size no matter what.
You only need the one single SD, which is tied to the one single LV. In your SD code, you’ll make use of the copy number to uniquely identify which sensor was hit. In your case, if you have multiple levels of replication (or multiple placements), you may need to make use of the G4Touchable and construct a combination of the direct object’s copy number, with the parent (or even grand parent) copy number, to ensure uniqueness.