JuliaPhysics/SolidStateDetectors.jl

memory usage

dustincombs opened this issue · 6 comments

Hi All,
I've constructed a 3 pixel planar detector and find that the field calculation is consuming 47GB of memory. I'm attaching my geometry file for reference. It's likely that I have something set up incorrectly. Any suggestions would be welcome.

simple_si_3hex.json.txt

lmh91 commented

Hey,
there is no issue with your config file.

Right now, contacts are also painted onto the grid. We need this in order to also recognize small/tilted/thin contacts on a coarse grid. The problem here is that you have large contacts. The painting is done via sampling the volume of the contact (a lot of points are generated -> high memory usage in that case) and each point is than mapped onto the next real grid point. In your case that is actually not needed. But right now, there is no direct way to disable it.

We are refactoring our CSG/Geometry right now #110 where we will solve this in a proper way.
But meanwhile we could add a small fix that one is able to disable the painting.

lmh91 commented

Okay, please have a look at the branch hotfix_disable_painting on my fork:
https://github.com/lmh91/SolidStateDetectors.jl/tree/hotfix_disable_painting

I introduced the environment variable SSD_DISABLE_PAINTING. If you set it, e.g. export SSD_DISABLE_PAINTING=true (in bash), SSD will not paint any contacts. This should make your simulation much faster as well.

Regarding your config file. I think the geometry of your semiconductor is not as intended? For a Tube, h in the config file creates a Tube which goes from z=0 to z=h. So I believe you want to change it to h = 2 and remove the translation.
(This will change in the future (#110) as we want to along with Geant-4 where Primitives are centered around 0).

Please let me know if it fixes your problem.

This works very well! Execution time is much faster and memory consumption is down from 47GB to 700MB. Thanks for pointing out the issue with the tube definition in the config file. Are there any other consequences to having the painting disabled (i.e. features that we will not be able to use or degradation of performance in other parts of the code)?

lmh91 commented

I don't think so. As long as you do not have thin&tilted contacts in your geometry you should be completely fine.
I will merge this into master soon.
Thanks for the feedback.

lmh91 commented

This hotfix is now included in SolidStateDetectors v0.5.1 and master.
I will leave the issue open until we have implemented it in a proper way.

lmh91 commented

Okay, the paining is now done directly and no array of points are generated temporarily anymore
(in SSD v0.6.0, which is already on the current master branch).

The environment variable SSD_DISABLE_PAINTING does not exists anymore inside SSD.
But in the three functions, simulate!(sim::Simulation, ...), calculate_electric_potential!(sim::Simulation, ...)
and calculate_weighting_potential!!(sim::Simulation, contact.id, ...) there are two keywords to control
how the contacts are painted on the grid:

  • not_only_paint_contacts::Bool = true: Whether to only use the painting algorithm of the contacts.
    Setting it to false should improve the performance but points inside of contacts are not fixed points anymore (which should not matter as they are enclosed by the fixed points of the surface due to the paining of the surfaces.)
  • paint_contacts::Bool = true: Enable or disable the paining of the surfaces of the contacts onto the grid.

Default is not_only_paint_contacts = true && paint_contacts = true.