﻿id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
4906	Memory management is extremely inefficient when running multiple simulations in a script	Francesco Casella	Adrian Pop	"I ran a script containing these two lines
{{{
simulate(ScalableTestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelicaIndividual_N_40_M_40, simflags=simflags, variableFilter="".*_[1-4]_[1-2]_.*|.*_10_10_.*"");getErrorString();
simulate(ScalableTestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelicaIndividual_N_40_M_40, simflags=simflags, variableFilter="".*_[1-4]_[1-2]_.*|.*_10_10_.*"");getErrorString();
}}}
on a Linux workstation with 20 CPUs and 72 GB of memory, using the latest nightly build.

The execution statistics for the first run were:
{{{
    timeFrontend = 16.558262787,
    timeBackend = 6.284129372,
    timeSimCode = 2.21432826,
    timeTemplates = 1.338698727,
    timeCompile = 4.979096652,
    timeSimulation = 1.897257977,
    timeTotal = 33.271994613
}}}
while the statistics for the second run were:
{{{
    timeFrontend = 1434.521649766,
    timeBackend = 6.789682942,
    timeSimCode = 1.347459057,
    timeTemplates = 1.554605467,
    timeCompile = 5.170174612,
    timeSimulation = 1.904497514,
    timeTotal = 1451.28830158
}}}

For some reason, the (old) front-end took almost 100 (!!) times longer to complete its job. Running htop, I noticed that while during the first run the average CPU load was almost 200%, thanks to the GC running in parallel on the other 19 CPUs, during the second run it was always stuck at 100%.

This could be a very serious problem if one wants to write scripts containing more than one simulation run. In fact, I just wanted to to do that to carry out the task described in #4885.

I am also a bit worried that this may also happen when using the various Java, Python, Julia, etc. interfaces to OMC, that may call simulate commands multiple times, with the same omc process running in the background

I guess this has to do with memory fragmentation and garbage collection. Isn't there any way to clean up the used memory once a call to simulate() has been completed, without the need to kill the omc process and restart it anew, so as to avoid this kind of problems? "	defect	closed	critical	1.13.0	Interactive Environment		fixed		Per Östlund Adrian Pop Martin Sjölund
