Problem 1937

Re-assigning to correct component

Reassigned

Dear Alexander:

Are you facing a memory accumulation over events when running the chemistry?

We'd be interested in accessing your code in order to be able to reproduce the issue you are facing. It would ease the bug tracking.

Meantime, there is a modification you could try in the geometry package:

Go to the file source/geometry/volumes/src/G4NavigationHistory.cc
Go to the G4NavigationHistory default constructor and replace GetNewLevels with GetLevels, so:

G4NavigationHistory::G4NavigationHistory()
  : fStackDepth(0)
{
  fNavHistory = G4NavigationHistoryPool::GetInstance()->GetNewLevels();
  Clear();
}

with

G4NavigationHistory::G4NavigationHistory()
  : fStackDepth(0)
{
  fNavHistory = G4NavigationHistoryPool::GetInstance()->GetLevels();
  Clear();
}

This fix is planned for 10.3-patch1. This should fix an accumulation of the navigation history levels over events.

In parallel and if this fix is not enough for you, please let us access your code with the needed macro for reproducing easily the bug.
If this fixes your issue, please let us know as well.

Best regards,
Mathieu

(In reply to Mathieu Karamitros from comment #3)
> Dear Alexander:
> 
> Are you facing a memory accumulation over events when running the chemistry?
> 

Yes, that is correct.


> We'd be interested in accessing your code in order to be able to reproduce
> the issue you are facing. It would ease the bug tracking.
> 
> Meantime, there is a modification you could try in the geometry package:
> 
> Go to the file source/geometry/volumes/src/G4NavigationHistory.cc
> Go to the G4NavigationHistory default constructor and replace GetNewLevels
> with GetLevels, so:
> 
> G4NavigationHistory::G4NavigationHistory()
>   : fStackDepth(0)
> {
>   fNavHistory = G4NavigationHistoryPool::GetInstance()->GetNewLevels();
>   Clear();
> }
> 
> with
> 
> G4NavigationHistory::G4NavigationHistory()
>   : fStackDepth(0)
> {
>   fNavHistory = G4NavigationHistoryPool::GetInstance()->GetLevels();
>   Clear();
> }
> 
> This fix is planned for 10.3-patch1. This should fix an accumulation of the
> navigation history levels over events.
> 


I will attempt this and post the results.


> In parallel and if this fix is not enough for you, please let us access your
> code with the needed macro for reproducing easily the bug.
> If this fixes your issue, please let us know as well.
> 
> Best regards,
> Mathieu


I will e-mail you separately with repository access.

The suggested fix did not work.  It was suggested via e-mail that an interaction with a UserTrackInformation class may be to blame.  I will investigate and report back.

After some testing, I determined that the problem seems to be an interaction between the physics lists "G4EmDNAPhysics", "G4HadronPhysicsQGSP_BERT", and "G4EmDNAChemistry".  The first two are sufficient to cause a loss of RAM, but including the chemistry list multiplies the effect.

I suspect further investigation into why this happens would require more familiarity with those physics lists than I have, but for my own purposes I believe I can work around it by assembling my own physics lists with only what I strictly need and avoiding overlap.

Created attachment 439 [details]
Using hadronic physics together with dna physics

When using hadronic physics together with dna physics, a lot of secondary electrons get generated by the dna physics. The user application should be divided into smaller components. See my other post

Dear Alexander:

Thank you for reporting your issues.

In your simulation you actually don’t use the chemistry, but you are trying to couple hadronic and dna physics. 
When beaming 1 GeV protons in your world, you need to take a relatively large geometry (at least cm). Your simulation uses a cubic world of 2 meters side.
Keep in mind that geant4-dna is designed for microdosimetry and intended for track structure studies. So if you try to record information at every physical step of an electron simulated using geant4-dna, you’ll quickly fill your memory.
Of course, if you add the chemistry on top of it, it’s going to be even worse as the chemistry simulates several tracks at the same time. There will be approximately 2.5 species generated by interaction point, given that geant4-dna explicitly simulates all interactions, it is just not possible to handle such a "big" volume.
Geant4-DNA is a track structure simulation that is intended to be used only on sub regions. If you want to combine standard EM and dna physics on specific sub regions, you may take a look at the microdosimetry example. But in your case, I would proceed slightly differently, see the end of this message.

In our exchange, you mentioned that you want to retrieve the positions of the chemical species generated by the physics stage, without actually triggering the chemistry. Therefore, you should not need to add G4EmDNAChemistry to your physics list, when doing so, you are activating the chemistry, which is not needed in this case of the positions of the species you are trying to output are provided by the physics stage. Anyway, given that you also rewrote the chemistry manager, you code prevents the activation of the chemistry module.

When rewriting the chemistry manager to output the positions of the species in your desired file format, you changed the interface of the chemistry manager, which creates a conflict with the chemistry manager enclosed in the library. As a consequence, your code is not compilable on my platform (macOS 10.12.3). To compile, I had to disable both your chemistry manager and your histogram manager.

Note that we cannot support a modified version of the library, we can however provide a hook inside the library so that you can output the desired information into whatever format you’d like. I started to work on such a hook, I’m waiting for the feedback from another category to complete the code.

You don’t run the chemistry. So, I analysed the memory allocation and leaks using « instruments » (shipped with Xcode) of chem3 + a spherical world of 3 cm radius + G4HadronPhysicsQGSP_BERT + G4HadronElasticPhysics + the proposed fix on the geometry package on 10.3, of course the chemistry was disabled. The increase of memory you see is related to the storage of the huge amount of secondary tracks generated in the large geometrical volume.
See the snapshot of the running application sent earlier.

In your case, you don’t run the chemistry, but you save information at every step.
Note that when using tuples or histograms, you may need to dump the data stored in memory into a file in order to release the memory. If you wait the end of the 10000000 events included in your run before doing so, you may see a huge amount of memory allocated only for handling your analysis, especially due to the fact that information is stored at every step of a track structure simulation. However, it may be that ROOT is managing the dump in a clever way to avoid filling the memory, though this is unsure.

I’m not sure what are your current plans for this application.
However, given the current scheme of your code, I would try to split the application. Here is what I would do:

1) In a first simulation, use the needed hadronic constructors and the EM standard physics (make sure the set of constructors you are using fit your simulation needs, you may send your questions on the forum). Select a sub region (e.g. a cube of 1 um side) of you world (a bit aside from the direction of your primary proton). Kill any particle entering this sub region but store, in a root file, their types (e-, photon…), energies, positions/directions…

2) Start your second simulation using the set of particles recorded in your root file. Use only dna physics in this simulation (possibly combined with EM std physics on specific energy range, see the microdosimetry example), store the positions of the chemical species in a root file.

3) If you are interested in running the chemistry stage, start a third simulation using the positions/types of the chemical species (cf. G4MoleculeGun) and the chemistry module alone.

This will take you some time… Good luck!

All the best,
Mathieu

> 
> 2) Start your second simulation using the set of particles recorded in your
> root file. Use only dna physics in this simulation (possibly combined with
> EM std physics on specific energy range, see the microdosimetry example),
> store the positions of the chemical species in a root file.


Ooooh, so DNAphysics is intended to run without any other physics?  While it's not seen in the simplified code, I had already split the geometry as suggested, but had merely copied over the physics list and added DNAphysics (and emdnachemistry).  I see now that that was not the proper way to do it.

Thank you for your help.

Oh and for those coming across this later, if you set it up correctly ROOT will dump to a file so that that data doesn't build up in local memory.

> Ooooh, so DNAphysics is intended to run without any other physics? 

Not exactly. The dna models follow the track structure approach and therefore account for all secondaries (unlike the condensed history approach). So it is rather intended to run on small volumes and specific energy ranges. At higher energy, you can use the std EM physics (see the end of this message).

The combination the physics constructors in your physics list (I'm not referring to the  combination of the EM models, but really to the "modular physics list") may lead to overlaps in the physics. For instance, you may register two types of ionization models for the same volume/material. This could happen if you just take out of the box a dna constructor plus one of the std EM constructors. You'll get too much energy deposition as the ionization of water would be included twice. Until recently there was no protection to prevent this type of conflicts.

This is why if you intend to mix several types of physics, it would be safer to first post your physics list on the forum for review.

To select the models on specific energy ranges, you need to apply a combinaison at the scale of the models (and not at the scale of the constructors). You may find the details of such a procedure in the microdosimetry example, but it is rather complicated. 

Fortunately, there is much (!) simpler approach but it is still experimental. If you'd like to give it a try, you may have a look at the microyz example (in extended/medical/dna). You won't need to register a dna physics constructor, only pick up a std EM physics for your particular problem and register in your macro the region where you'd like the dna physics to be applied.
If you find bugs, please report them here (on a new thread), it would be useful.

I'll take the physics list back to the example I originally pulled from and modified, then.  If I find anything else that I think are bugs, I will certain report on the tracking system.