FASTv8 + Memory Leakage + Restart Capability

[Bastian.Ritter]

Good morning,

first of all, thanks for providing such an excellent place for interesting discussions about FAST!

I have two issues which I have encountered lately using the FAST/Simulink interface of version 8.12/8.15.

The first one concerns the so-called Checkpoint-Restart capability which was added in FASTv8.12. As background information: I am using this feature to perform distinct Checkpoint restarts (let’s say every 10 milli-secs) since the Checkpoint restart is up to now the only way to initialize FAST/Simulink with all its internal states accurately. My implementation worked good so far with FASTv8.12 if the simulation time remains small.

Though, the problem with this feature “Chkpoint-Restart” is in general that on every restart from a Checkpoint file the “Matlab used memory” rises by approx. 5 MB. Unfortunately, the allocated memory by the Rountines “FAST_Restart()” or “FAST_CreateCheckpoint()” is NOT set free after restart.

Thus, it accumulates and Matlab breaks eventually down due to “Out of Memory” error (in my case after ~1000 iterations equival. to additional 5GB memory usage). Since the memory is allocated by the Fortran FAST_Restart() Routine and not by the Simulink sfunction directly, I haven’t found a suitable way to resolve this issue yet.

I think, there is an awareness for this problem since in the README_FAST8.pdf it says:
“Before FAST creates a checkpoint file, it doubles the amount of memory in use in the simulation because all of the data is packed into three arrays that are then written to a file. Thus, it is likely that 32-bit simulations will not be able to create checkpoint files”.

Has someone else encountered this effect before and might know a solution to it?

The second issue:
Apart from problem 1, I migrated my simulation environment from 8.12 to 8.15. After updating the FAST-Inputfiles and copying the new FAST-code (FAST_Library_x64.dll, FAST_Library_x64.lib and MAP_x64.dll) the simulation worked perfectly. But only as long as I do not request a FAST_Restart() explicitly. If the latter routine is called now (with FASTv8.15), Matlab breaks also down when trying to execute FAST_Restart() from the simulink sfunction.

Since exactly the same code worked - in general - perfectly with FASTv8.12 and I only changed the above mentioned Inputfiles and FAST source code, I do assume that the problem lies within the fortran code.

What has changed in the new version of FAST compared to the one from last October with respect to the restart-capability?

Kindest Regards from Germany,
Bastian

[Bonnie.Jonkman]

Hi, Bastian.

The text you mention in the FAST ReadMe does not refer to a memory leak. FAST stores almost all of its data in data structures. When it creates a checkpoint file, FAST creates three arrays (integer, single-precision real, and double-precision real) and copies all of the data from the structures into these arrays that can then be written to a file. When these three arrays are allocated, they effectively double the memory of the FAST simulation. They are deallocated after the routine exits, so that does not produce a leak (I did notice that if the routine returns an error, the arrays can sometimes remain allocated, so I have fixed that, but this problem wouldn’t be noticeable in normal use).

The restarted simulation will use slightly more memory than the original (only because the original uses pointers in the mesh structure and sibling meshes point to the same shared memory; on restart, the sibling meshes aren’t actually pointing to the same shared memory; they each have their own). However, if you restart from a restart, the memory shouldn’t increase. It’s a one-time increase.

The FAST restart/checkpoint capability is not part of the Simulink interface that NREL distributes, so the memory leak could be a result of the implementation of this capability. The Restart routine assumes that the data structure is empty before it is called. When you create a checkpoint file, are you then destroying the data in the FAST_Library dll before you call the restart routine (for example, calling FAST_End)? If not, I can certainly see that the pointers in the mesh data structures would cause a memory leak.

The only thing that has changed with respect to restart capability between v8.12 and 8.15 is an INTENT statement in the Restart routine. In v8.12, the full simulation data was intent(out), which means Fortran automatically cleared the memory (setting pointers to 0 instead of freeing the memory they pointed to). In 8.15, I had to make it intent(inout) so that it would compile in gfortran. Again, if you hadn’t freed/destroyed the data before calling Restart, this could cause the problem you are seeing between the different versions.

If you can’t call FAST_End in your Simulink code, you can add a statement to the FAST Restart routine to make sure the data is destroyed before it uses the data structure. In FAST_Subs.f90, add this line at the beginning of the FAST_RestoreFromCheckpoint_T() routine:

call FAST_DestroyTurbineType( Turbine, ErrStat2, ErrMsg2 )

Then recompile the FAST_Library DLL.