I am trying to simulate a prototype sensor that has been used in measurements, just to double check the results from Allpix.
The prototype have a guard ring structure in front of the pixels, and a row of floating pixels behind the first row of pixels closest to the guard rings.
I have simulated the full field of the sensor with the guard rings in front and the floating electrodes behind, and cut off the field such that the row of connected pixels are in the center of the field with as much area behind the connected pixels as in front of them in the y-direction.
To accomodate the extra area in front and behind of the connected row, I assumed that I could use the sensor_excess_<direction> when configuring the detector, with direction = top & bottom, and set the field_mapping = SENSOR in [ElectricFieldReader].
I am getting the following warning when running Allpix: Field map size is (98um,1.062mm) but expecting a multiple of the pixel pitch (14um, 504um). The area to which the field is applied can be changed using the field_scale parameter.
I am getting the same warning for the weighting potential, where I have used a similar approach, but cut of the field in the pixel width (X-direction) such that the pixel with unit potential is in the centre of 3 pixels.
Now to my question: What is the proper procedure to accomodate the excess of the sensor where the guard ring structure is located as well as where the unconnected (floating) electrodes are?
this is an excellent topic you are bringing up - so far we do not have a possibility to provide a “full sensor” field including excess, but your approach actually seems quite sensible.
For the sensors I personally look at, simulating even more than a couple of pixel together is unfeasible since the meshing is too fine. If this is, however, possible, including the sensor edge seems like a natural thing to do.
I will have a look how this could be added to the different field mapping options already present. @hwennlof maybe you also have an idea?
I guess one way to include the guard ring would be to add a row or two of dummy pixels, and use field_mapping = SENSOR if you have simulated the field across your full pixel matrix as well as the guard ring. This just requires a little tweaking of the initial field size, so that the excess matches an integer number times the pixel pitch.
So, for a more practical description of my thought, if your active area is 20x20 pixels, you would simulate the edge region as well at up to the distance of a full pixel in each direction, and then you can use number_of_pixels = 22 22 in Allpix Squared along with field_mapping = SENSOR to get this accurately mapped.
Maybe you could tile it in your external software in order to get floating pixels behind and guard ring in front, and then import the field like this.
However, this comes with some drawbacks (such as a signal being generated in the dummy pixels, which can be solved in the analysis, but still), and a better way would be nice. This is what’s possible right now, however.
Currently the sensor_excess is just empty detector material without field. I guess what we would like to do is be able to define a field in there, but I struggle a bit to see how best to do it right now.
Maybe we could add keywords to ElectricFieldReaderModule to allow for setting more than one field, and calculate an offset to put the other field into just the excess. Lots of checks and balances needed though, but clever use of offset and setElectricFieldGrid might work…
The straight forward solution was to, since I am using the weighting potential, set the pixel size to the full field size including the guard ring structure and what not, since the collected charge is dependent on the weighting potential anyways.
If I can make a suggestion based on my intuition reading the docs, when defining excess and using the mapping SENSOR, intuitively one would assume that the field would be applied on the full sensor, which would then include the excess. If the mapping SENSOR do not take the excess into account, I am a bit at a loss why the option of defining excess is there, especially since there is no field there anyways.
This way one is not restricted to using the weighting potential, and can use simpler/faster propagation as well.
In most cases the precision of fields used renders a full-sensor coverage of the file impossible. This is the reason for SENSOR being the keyword for the APSQ 2.x way of replicating a field in a flexible manner over the sensor area, e.g. featuring double columns or other repeated structures.
I can cover for your loss. The reason is the physical extent of the silicon in Geant4, in which scattering etc occurs. We indeed do want to add simulation of guard rings and the likes at some point, we just have not worked on it yet because in our application scenarios with rather large sensors and rather slim guard ring regions, in analyses this part (including the outermost ring of pixels) is often discounted because of its different response compared to the rest of the matrix.