BUG: Memory Leak during VTK output

[MaxOkraschevski]

Using the write() method of a VTKFile object in a time stepping loop for a PeriodicSquareMesh() in 2D with DG0 leads to a quick memory accumulation when executed in parallel. This persists even without the solve() call (the red line representing memory):

This was observed running the following script:

01_Rivera2D.txt

The problem seems to be independent of the core number as long as run in parallel (n>1).

I also tested for this behaviour using another 2D problem with DG0 on a RectangleMesh(). Interestingly, without solve() call the problem persists again, however with a solve() call the memory usage is stable. To me it seems that memory allocated within the VTKObject is released in the solve() call depending on the chosen MeshUtility.

[connorjward]

The dependence on the type of mesh is very strange.

In general if you are:

• Running in parallel, and
• Not calling solve()

Then memory consumption is expected to increase because we call PETSc.garbage_cleanup() inside solve (here). Without this a large number of objects will not be cleaned up. Adding calls to garbage_cleanup will almost certainly help, but the behaviour with the periodic mesh is still very odd.

[ksagiyam]

Yes. With the latest master, I confirm that adding the following lines keeps the memory usage from increasing:

for ...
   ...
    gc.collect()
    PETSc.garbage_cleanup(comm=mesh._comm)

(Please note that a potentially relevant PR has been merged #4033, so I suggest that you update your Firedrake.)

[MaxOkraschevski]

@connorjward: Okay, if this is by construction, then my conclusion on the memory leak was wrong and this issue/thread is pointless.

My original problem was that this script freezes in parallel during the vtk output at a certain point in time. On the slack channel we already started to discuss with @ksagiyam how to debug this issue and he recommended to try whether the freezing persists without the solve call to speed up debugging. This is how I came to the conclusion that the problem is related to a memory leak. Actually, I verified over the weekend that this is not the case (180 GB memory available) :

I still dont know why it freezes but I worked out that this issue can be circumvented by extruding the mesh into 3D with one cell in the third dimension...

[connorjward]

I see. I will close this issue then. Feel free to open another regarding your other issue. Though if you have a workaround it may be some time before someone is able to look at it.