Memory runaway when using AdaptiveEpsilonConstraintHandling with save_history=True in U-NSGA-III

[TSVermeulen]

I am using the U-NSGA-III algorithm to solve an aerodynamic (black-box) propulsion optimisation problem. For those interested, the code is available on my public repository here.

For this particular problem, there is only one objective: the propulsive efficiency. When using the feasibility-first constraint handling with save_history=True, memory usage is perfectly fine on a typical run (population size of 100 with a maximum of 100 generations). However, using save_history=True with the AdaptiveEpsilonConstraintHandling seems to eat memory like teenage me during breakfast. I have had to stop my code at generation 16.

In this generation, the time between the end of analysis of a current generation and the start of the next generation blows up exponentially, while the baseline memory load increases from a default of ~20GB (I am using a starmap parallelisation with 61 processes) to over 180GB.

[blankjul]

wow. seems like a memory leak. Can you try the current version in the main branch?
I have with a recent commit switch to wrapt.ObjectProxy for the Meta object inheritance (this is what is used by AdaptiveEpsilonConstraintHandling).

Let me know if the issue this persists. If yes, I would like to ask you to provide some code to reproduce the memory leackage,

[TSVermeulen]

Hi Julian,
I am currently running an analysis with save_history=False on the departmental server at my university. As soon as this run is finished, I will try your suggestion.

If you need me to, I'm happy to share my code and provide the relevant code segments. However, my developed algorithm interfaces with my developed "Unified Ducted Fan Design and Analysis Code", which, in turn, builds on MTFLOW by MIT. Since MTFLOW is licensed, I cannot share the complete working algorithm, but only my own developed Python code, so I do not know how useful this will be.

I will report back once I have run the updated main branch code.

Best,
Thomas

[blankjul]

Great!

fuzzing around with third-party libraries will take quite a bit of time. I would prefer if you can re-produce the error by mocking the evaluation (should be no issue if the memory leackage is within pymoo right?)