I would like to simulate a simplified system that uses an ionization chamber to measure the dose of a proton therapy device. The schematic diagram of the system is shown in the figure. The configuration file for Allpix² is attached. The current issue is that when runningallpix -c simple_main.conf, the system crashes. Could you please advise on what might be wrong with the configuration? Thank you very much.
Very interesting application! There seems to be a bit of confusion here however.
The main reason for the segmentation violation is that “air” is not a valid sensor material in Allpix Squared. A list of the currently available materials for the sensitive part can be found here. We should probably add an error message for a situation like this.
In general I would recommend reading through the documentation a bit more, and maybe have a look at a tutorial (e.g. from the last BTTB workshop, here).
Some keywords in the configuration are incorrect (this is also reported in log messages when running the simulation), e.g. source_energy, source_position, and beam_direction in the [DepositionGeant4] configuration.
The detector configuration is not touched upon so much in the linked tutorial, but there are examples in the repository (in the models directory), and quite a bit written about it in the manual, and I think it would be good to look into in a bit more detail.
The sections [anode], [cathode] and [entrance_window] are not valid in this way. You can define passive material in your assembly by using the [support] keyword, and then you could set a linear electric field in your sensitive volume in the main configuration file using [ElectricFieldReader] for example, to emulate your situation. However, as I mentioned, air is currently not an available sensor material.
Thank you very much for your help. I still have a few questions to ask.
First, the reason ALLPIX cannot be used is that its current framework does not support the material property ‘AIR’. I would like to know if ALLPIX has any plans to add the ‘AIR’ material, or if I can add ‘AIR’ myself by modifying the source code? Since ALLPIX is a simulation software for solid-state detectors, I’m not sure if simply adding the ‘AIR’ material would be sufficient to achieve simulation of a gas-based parallel-plate ionization chamber?
If it’s not possible to easily modify ALLPIX to achieve parallel-plate ionization chamber simulation, then CERN’s other gas detector simulation framework, GARFIELD, can support parallel-plate ionization chamber simulation. However, GARFIELD itself does not support electronics simulation. Could I take the current waveform output from GARFIELD simulation and input it into the CSADIGITIZER module within the ALLPIX framework, thereby using ALLPIX’s electronics simulation to complete the simulation chain from proton beam → parallel-plate ionization chamber → front-end electronics, and thus obtain the electronics output?
Feel free to add air as a sensitive material if you want, it is certainly possible and not so difficult for an initial study, even if the details likely require more. So far Allpix Squared has to my knowledge not been used for gaseous detectors, but it should be quite possible. You would have to add the material properties, and then also an appropriate mobility model. A modification of the propagation module might be in order, as we in Allpix Squared generate and propagate electrons and holes, but in a gas you would get ions. But, certainly possible.
For Garfield++ integration, this would also be possible, with some coding. I am not intimately familiar with the Garfield++ output format, but I think the easiest would be to write a ROOT script starting from the [CSADigitizer] code, and then make the input a pulse that you extract form the Garfield++ output, if you want to go this route.
In Allpix Squared, a current waveform is basically an extended std::vector<double>, and it would be relatively straightforward to use this as input and then perform the function of [CSADigitizer] in a script.