Hi @CaratheodoryRR
I can confirm this problem with an even simpler set up (removing the source composition and the redshift). I have not yet any idea where this is exactly coming from. Maybe the dereferencing for break conditions is handled differently from observers...
I'll keep you updated on any progress.

Edit:

• Adding an output for the break condition is not helping.
• A similar behaviour is found for other break condition, e.g., SphericalBoundary(Vector3d(0), 2000 * Mpc)). So I guess this is connected to the underlying class AbstractCondition

A hacky solution would of course be to cut the simulation into smaller pieces (reducing the number of Candidates per run) so that the memory is large enough.

If anyone knows the difference of the memory handling between Observers and AbstractCondition it might help to understand why one is working and the other not.

A hacky solution would of course be to cut the simulation into smaller pieces (reducing the number of Candidates per run) so that the memory is large enough.

If anyone knows the difference of the memory handling between Observers and AbstractCondition it might help to understand why one is working and the other not.

Did you test it? Because I already do that in my program and I am facing the same problem. The RAM usage keeps growing monotonically over time, and the only way to free up memory is terminating the program.

PD: I accidentally closed this issue, sorry for that.

Hey
I also found this strange memory consumption. I have no Idea for the reason.
A workaround would be switching to observer based detection of the maximum trajectory length.
You can either use the ObserverTimeEvolution or write a simple Observer feature for this (see https://github.com/JulienDoerner/CRPropa3/tree/issue_493). In this case I tested that the memory does not increase.

Did you test it? Because I already do that in my program and I am facing the same problem. The RAM usage keeps growing monotonically over time, and the only way to free up memory is terminating the program.

Yes, the RAM will still grow over time, but if the simulation finishes before the RAM is full the results should be fine, shouldn't they?
This is by no means a nice solution but might help in cases where you cannot use an observer as described by @JulienDoerner.

Hey I also found this strange memory consumption. I have no Idea for the reason. A workaround would be switching to observer based detection of the maximum trajectory length. You can either use the ObserverTimeEvolution or write a simple Observer feature for this (see https://github.com/JulienDoerner/CRPropa3/tree/issue_493). In this case I tested that the memory does not increase.

Hello @JulienDoerner, thanks to you and @lukasmerten for your replies. This observer-based approach solved my memory issue. I also added some code for the minimum energy condition as an observer feature, and it works!

This memory problem haunted me for a couple of months and it prevented me from making progress in my research. I understand this is a temporary solution though, so any updates regarding the memory handling of the AbstractCondition class would be gladly received.

I reproduced the bug by running a simpler version only with c++

#include "CRPropa.h"

using namespace crpropa;

int main(void) {
    ModuleList sim;

    sim.add(new SimplePropagation(1 * Mpc, 100 * Mpc));
    sim.add(new Redshift());
    sim.add(new MaximumTrajectoryLength(2000 * Mpc));

    ref_ptr<Observer> obs = new Observer();
    obs -> add(new Observer1D());
    sim.add(obs);

    Source source;
    source.add( new SourceUniform1D(1 * Mpc, 1000 * Mpc) );
    source.add( new SourceDirection(Vector3d(1, 0, 0)) );
    source.add( new SourceRedshift1D() );

    // run 
    sim.setShowProgress(true);
    sim.run(&source, 100000000, true);
}

The memory issue seems not be related to the SWIG interface but rather the C++ module handling.

I traced the issue down to the rejectFlag which is set on each deactivation.

By default the key is "Rejected" but there is no rejectFlagValue.

One can solve the issue by setting the rejectFlagVlaue directly:

sim = ModuleList() 
max_tra = MaximumTrajectoryLength(1 * Gpc) 
max_tra.setRejectFlag("Rejected", "maxTra")
sim.add(max_tra)

I would suggest to add a default value for the flag based on the module name. This should solve the problem for all abstractConditions