I think I have found a memory leak in OpenMDAO, that occurs when resetting a problem and computing the total derivatives several times. Here is a way to reproduce it with the Sellar problem:
import openmdao.api as om
from openmdao.test_suite.components.sellar_feature import SellarMDA
# Setup of the Sellar poblem
prob = om.Problem()
prob.model = SellarMDA()
for i in range(10000):
# prob = om.Problem() ### adding these two lines solves the memory leak
# prob.model = SellarMDA()
prob.setup(check=False)
prob.model.cycle.linear_solver = om.DirectSolver()
prob.run_driver()
totals = prob.compute_totals("z", "x")
del totals
input()
When I launch this script, the RAM gets filled and is not freed until the running terminal is closed. Killing the script does not free the memory, nor does deleting the totals object. The memory leak seems to happen only when using compute_totals with finite differences. I found that recreating the problem (the two commented lines) instead of only resetting it prevents the leak.
My current version of OpenMDAO is 3.2.0, but I managed to reproduce it on 3.3.0 too.
I am not sure if I am doing something wrong or if it really is a bug, but I am interested if someone has an explanation. It is easy to avoid the leak, adding the two commented lines is enough, but I still lost a few days of computation because of this and I thought I could document it for others.
I ran your test case and was able to reproduce the memory error. However, I found the problem remained even if I switched to fully analytic derivatives. There is definitely a minor bug there, but the memory leak is triggered by the repeated call to
prob.setup(). When I moved the setup call out of the for loop, the memory problem went away. So something is slightly leaking in setup, but its also not at all needed to re-call setup more than once, unless you're changing something in your problem that swaps a variable size or otherwise actually requires it.I'll assume in your actual run script you do need to call setup more than once, and that is why you ran into this bug. I've logged the bug in the OpenMDAO issue tracker on GitHub.