Allpix Squared merge requestshttps://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests2024-03-27T15:00:53+01:00https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1101Docs: add Silvaco parser to MeshConverter documentation2024-03-27T15:00:53+01:00Simon SpannagelDocs: add Silvaco parser to MeshConverter documentationFeature 3.1.0https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1097WIP: scoring manager detecting particles passing through defined plane2024-02-05T14:10:10+01:00Tobias BisanzWIP: scoring manager detecting particles passing through defined plane# All here is WIP
## What?
We're currently investigating slabs ob diodes sandwiched between absorbers and want to understand how (many) particles leak out/how secondaries behave.
## How?
The idea was to log if particles cross a certa...# All here is WIP
## What?
We're currently investigating slabs ob diodes sandwiched between absorbers and want to understand how (many) particles leak out/how secondaries behave.
## How?
The idea was to log if particles cross a certain plane, then write them out as `MCParticle`s and allow later (re)processing. Ideally, there should be no need to interfere in any way with the existing geometry. The implementation allows to define planes and a G4 stepping action hook is used to write out the data. This does slow down the simulation a bit, numbers still need to be put on this; however, it should not change any of the charge deposition/interaction process.
## The ugly
We're abusing some things in AP2 here. I don't like this, but at the same time, adding more very basic components might also create more noise.
### Abusing `Detector`
In order to reuse the facilities which allow to process the geometry file and attach MCParticle messages to Detectors, the Detector class is used. However, the detectors here don't have a model, no pixellisation, and are also not really properly implementing some other required fields. The `GeometryManager` has been taught that there are things called scorers ... which are `Detector` but are not linked to any G4SensitiveDetector.
### Abusing `MCParticle`
MCParticle are short tracklets passing through a SensitiveDetector ... up to now. Now they also represent a particle crossing the plane. This makes start/end position a bit useless. However, the start position marks the point on the plane and then the stop position is once step along the trajectory. I have a gut feeling, that this is not tragic.
### Blowing up the ModuleManager
Since the new "scoring" detectors also need to have modules to process the hits and fill histogramms, they were partially added to the ModuleManager. However, only for modules which specify a `name` and in addition, since multiple instances with different options might be used, an `instance` keyword was added to allow multiple instances of this same module with different options.https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1077Draft: DepositionGeant4: Allow for a beam of rectangular and elliptical shape.2024-03-26T11:07:35+01:00Naomi Afiriyie DavisDraft: DepositionGeant4: Allow for a beam of rectangular and elliptical shape.
The option of having a rectangle and ellipse beam in the `DepositionGeant4` module was added.
The histogram `incident_track_position` visualises the beam in 2D.
Below, there are examples for the `Rectangle` and `Ellipse` beam.
The di...
The option of having a rectangle and ellipse beam in the `DepositionGeant4` module was added.
The histogram `incident_track_position` visualises the beam in 2D.
Below, there are examples for the `Rectangle` and `Ellipse` beam.
The dimensions are specified with the `beam_size` parameter, by giving either one or two values.
If only one value is specified the length in x and y are equal (the beam sigma in x and y for the ellipse).
If two values are specified they should correspond to respective parameters in x and y.
As the `beam_size` key can take one or two parameters, backwards capability is ensured when going for the default circle beam with one
`beam_size` value for the beam sigma in r.
One remaining issue is that for some reason the `beam_size` parameter when given two values, switches x and y.
The configuration for the rectangle beam shown below was as follows:
```
[DepositionGeant4]
source_type = "beam"
flat_beam = true
particle_type = "e-"
source_energy = 5GeV
beam_size = 3mm 4mm
beam_shape = Rectangle
beam_direction = 0 0 1
model = "fixed"
source_position = 0 0 -10mm
output_plots = true
```
In the resulting plot, however, it is exactly the other way around with a length in x of 4mm and in y of 3mm.
[incident_track_position_rectangle.pdf](/uploads/3aa442368b5f6f47e85c0d180d025941/incident_track_position_rectangle.pdf)[incident_track_position_ellipse.pdf](/uploads/d01b9392ff6f22a9a50a5e8d0d626d3d/incident_track_position_ellipse.pdf)https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1072Draft: Auto-Publish to Zenodo (and RSD) using hermes2023-10-13T15:55:17+02:00Simon SpannagelDraft: Auto-Publish to Zenodo (and RSD) using hermesThis MR will add `hermes` to the CI deployment workflow (https://docs.software-metadata.pub/en/latest/index.html).
`hermes` is capable of auto-publishing releases to e.g. Zenodo where - up till now - we had to manually update our relea...This MR will add `hermes` to the CI deployment workflow (https://docs.software-metadata.pub/en/latest/index.html).
`hermes` is capable of auto-publishing releases to e.g. Zenodo where - up till now - we had to manually update our release entry (https://doi.org/10.5281/zenodo.3550935).
This is still a draft and has to be tested and refinded.https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1069Draft: Add Electric Field Option for Gain Layers2023-09-15T14:55:59+02:00Simon SpannagelDraft: Add Electric Field Option for Gain LayersThis is the first port of @fdewit's work on gain reduction mechanisms to the main repository.
All code is from @fdewit, my changes only concern
* Formatting
* Some readability & rebase to latest `master`
* Documentation, taken from @fde...This is the first port of @fdewit's work on gain reduction mechanisms to the main repository.
All code is from @fdewit, my changes only concern
* Formatting
* Some readability & rebase to latest `master`
* Documentation, taken from @fdewit's thesis
For reference, the thesis can be found here: https://www.ru.nl/publish/pages/913454/2023_femke_de_wit_thesis.pdf
To do:
* [ ] Add test cases based on examples from @fdewit
* [ ] Ensure that this also works e.g. with an iLGAD sensor or with an *n* bulk sensor
* [ ] Finish documentationFeature 3.1.0https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1041Charge carrier reflection on surface2024-03-26T11:34:44+01:00Ben BruersCharge carrier reflection on surfaceThe surface reflection introduced in MR !1014 is modified as follows:
- the electric field and doping concentration for the diffusion modeling are taken from the position before the drift modelling (`last_position`) as also addressed in ...The surface reflection introduced in MR !1014 is modified as follows:
- the electric field and doping concentration for the diffusion modeling are taken from the position before the drift modelling (`last_position`) as also addressed in !1035. This avoids that the diffusion uses a null field / concentration, if the charge carrier drifts outside of the sensor
- the charge collection and surface reflection are carried out before other effects, such as trapping, recombination, etc. are modeled. Otherwise nonphysical effects are observed
- the surface effect is modified to actually reflect the charge carrier at the surface (note the z-position change). This is necessary to avoid nonphysical behavior, if e.g. the electric field at the surface is zero. The current implementation may lead to charges "bouncing" along the surface (which is also somewhat nonphysical). Yet, this is observed to model the measurement well
- currently the reflection is only implemented for the z-boundary of the sensor. Other use-cases seem unlikely, yet we can discuss this
Finally, the author-list has been updated, adding @cscharf and me.
Tagging @cscharfhttps://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1013Fast Masetti and MasettiCanali Models2024-03-13T11:19:52+01:00Simon SpannagelFast Masetti and MasettiCanali ModelsThis adds a tabulated `pow` implementation with logarithmic binning, making it possible to cover huge ranges like required for the doping concentration of the Masetti models, covering 1e13/cm^3 - 1e20/cm^3 of relevant doping concentratio...This adds a tabulated `pow` implementation with logarithmic binning, making it possible to cover huge ranges like required for the doping concentration of the Masetti models, covering 1e13/cm^3 - 1e20/cm^3 of relevant doping concentrations.
Using this, there is a `masetti_fast` and a `masetti_canali_fast` model, the latter performing like this:
### At effective doping of 1e13/cm^3
![imcf_e_1e13](/uploads/2549510cd3bc739ef25e4aedf9f32723/imcf_e_1e13.png) ![imcf_h_1e13](/uploads/1214b9bbda853b3d28713e86fec71db7/imcf_h_1e13.png)
![mcf_e_1e13](/uploads/4498deceecabbf0fab797e2082cfb930/mcf_e_1e13.png) ![mcf_h_1e13](/uploads/520bcadac3dfa089fe0b6100546efa89/mcf_h_1e13.png)
### At effective doping of 1e20/cm^3
![icanali_e](/uploads/20020bb447b3d67e7c712a32e3ff09ac/icanali_e.png) ![icanali_h](/uploads/815fed52964c0bbdd61ba50446290912/icanali_h.png)
![canali_e](/uploads/e3d1b83db84f795f9bac1da5b24d5ced/canali_e.png) ![canali_h](/uploads/de62a7b5728c405cca706bc87af3fbde/canali_h.png)https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/1000Draft: Impact Ionization: Find Field Edge with Binary Search2024-03-26T11:34:44+01:00Simon SpannagelDraft: Impact Ionization: Find Field Edge with Binary SearchThis Mr implements a subsampling of individual charge carrier steps in case a strong electric field gradient is found. The edge position within the step is calculated using an efficient binary search with nanometer step width.
The calcu...This Mr implements a subsampling of individual charge carrier steps in case a strong electric field gradient is found. The edge position within the step is calculated using an efficient binary search with nanometer step width.
The calculated fraction of the step propagated in the high-field region is then sued to scale the step length used to calculate the local gain factors. Here, the higher of the two field values (pre- or post- step) is then taken, making this a more precise estimate both for steps into but also out of the gain region.
There are a few open questions and items to address:
- [ ] I reintroduced the threshold field to have a handle on *when* we consider something a high-field region, and also what edge value to search for. Does this make sense?
- [ ] We could think of placing the secondaries either at pre- or post-step positions depending on where the higher field is (stepping into or out of the high-field region)
- [ ] The entire propagation code becomes a bit spaghetti-like, and I'd love suggestions on how to nicely refactor this into some farfalle.
- [ ] We currently have quite some performance impact, not necessarily by the binary search (just some field lookups) but by impact ionization in general. Do be inverstigated
- [ ] We should benchmark this in terms of physics performance. @pschutze ?
P.S.: MR 1000 :tada:Feature 3.1.0https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/951Draft: add Cons passive model2023-09-13T15:37:47+02:00Renato QuaglianiDraft: add Cons passive modelIn developing a custom LHCb simulation (simplified) i had to include a beam-pipe passive material geometry.
The addition allows to parse a generic Cons.
Being the first contribution to the project, let me know if there are additional ch...In developing a custom LHCb simulation (simplified) i had to include a beam-pipe passive material geometry.
The addition allows to parse a generic Cons.
Being the first contribution to the project, let me know if there are additional changes to do.
To review:
+ what to put as max size?
+ example updated and checked.
Effectively what I want to ultimately add to the simulation with allpix-squared is an element defined like this in the GDML file i am depacking
```
<cone aunit="deg" deltaphi="360" lunit="mm" name="MagnetCons0xfebe9a0" rmax1="50" rmax2="141" rmin1="0" rmin2="0" startphi="0" z="4920"/>
<tube aunit="deg" deltaphi="360" lunit="mm" name="ExitWindowInnerRingTubs0xf54d860" rmax="35" rmin="20" startphi="0" z="132"/>
<tube aunit="deg" deltaphi="360" lunit="mm" name="ExitWindowOuterRingTubs0xf54e810" rmax="50" rmin="35" startphi="0" z="132"/>
<tube aunit="deg" deltaphi="360" lunit="mm" name="VeloPixSupportTubs0xf550650" rmax="250" rmin="0" startphi="0" z="1170"/>
```
Which means i probably also need to add ```G4Tubs``` model , but i guess Cylinder model is the same ?https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/944Draft: Allow specifying Material for Implants2023-01-30T11:15:04+01:00Simon SpannagelDraft: Allow specifying Material for ImplantsThis is an attempt towards #259 but needs more work with Geant4.This is an attempt towards #259 but needs more work with Geant4.https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/931p-cosmics-area2024-03-13T15:31:22+01:00Daniil Rastorguevp-cosmics-areaCloses #256Closes #256Daniil RastorguevDaniil Rastorguevhttps://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/930First implementation of QDC digitized charge data in the detector histo module2023-09-07T14:27:24+02:00Tobias BisanzFirst implementation of QDC digitized charge data in the detector histo moduleThe DetectorHistogramming modules assumes that all charge is in units of electrons. However, charge can also be in QDC units if digitized. In the latter case, two things must be handled differently:
* histogram limits and labels set acc...The DetectorHistogramming modules assumes that all charge is in units of electrons. However, charge can also be in QDC units if digitized. In the latter case, two things must be handled differently:
* histogram limits and labels set accordingly
* interpretation of the data, i.e. calls to `Units::convert` which are used to convert electrons into ke must not be madehttps://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/663Draft: Build Detector Models as Separate Library2023-01-26T11:49:38+01:00Simon SpannagelDraft: Build Detector Models as Separate Librarywith more and more different detector models and geometries added, it somehow doesn't feel optimal anymore that these models all live on `src/core/geometry`. This MR moves them to `src/detectors` and builds a separate shared library `lib...with more and more different detector models and geometries added, it somehow doesn't feel optimal anymore that these models all live on `src/core/geometry`. This MR moves them to `src/detectors` and builds a separate shared library `libAllpixDetectors.so` for them. This work has mostly been facilitated by @rprivara's nice work of fleshing out a separate `PixelDetectorModel` class.
This has some implications
* This library needs to link against `libAllpixCore` since we still rely on the base `DetectorModel` class which remains in `src/core/geometry`.
* The factory building detector models cannot live in the `DetectorModel` class anymore, but has to be implemented in the separate library now where all derived model implementations are available.
* The `GeometryManager` does not have direct access to that library, otherwise we would have a cyclic linkage dependency (`libAllpixDetectors` links to `libAllpixCore`, so `libAllpixCore` cannot link to `libAllpixDetectors`).
* The latter means we have to pass some `std::function` (or similar) to the `GeometryManager` to be able to create instances of detector models from the new library. This is a but clunky but I didn't have a better idea (borrowed from !179)
* Of course some header inclusion paths and sources to include in the `tools/` part of things have changed.
Very likely there are things to improve before this should be merged:
* Does anyone have a better idea than the current `DetectorModelFactory` method?
* Maybe #224 should be implemented, but this can also happen afterwards
* I would really love to have !539 merged before, otherwise this rebase will be a total mess.https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/350WIP: Add Tests for Framework Tools2023-07-10T15:21:03+02:00Simon SpannagelWIP: Add Tests for Framework ToolsOnce notoriously under-tested are of the framework are the tools for generating field files, converting them etc.
This MR aims at adding tests fro each of them by providing sample data, converting it and checking the resulting field usi...Once notoriously under-tested are of the framework are the tools for generating field files, converting them etc.
This MR aims at adding tests fro each of them by providing sample data, converting it and checking the resulting field using the `dump_header` tool. This MR is `WIP` because
* [ ] we need to add more tests to catch different code paths of the tools
* [x] we need to prepare better example field files than the one we currently have
* [x] we need to find a way to provide sample data to the CI runner without committing large files to git