Possible memory leak

[IrisMeasure]

Bug description
Memory leaks may occur when using binary compiled with the IFX compiler in Intel oneAPI 2025.0.0 or 2025.0.1.
When running the OpenFAST binary (version 4.0.0, IEA Wind 15-MW RWT) compiled with the IFX compiler, memory usage gradually increases from ~1.5 GB to approximately ~10 GB (single precision, after ~1 hour) during the time-history analysis phase.
This phenomenon also occurs with 5MW_OC3Mnpl_DLL_WTurb_WavesIrr in the r-test, but since this model is much smaller, memory usage increases from ~30 MB to ~120 MB (after ~1 minute).
This does not occur when using the precompiled binary (openfast_x64.exe) from the release. I am uncertain if this behavior should be considered a memory leak, or if it is a designed feature of OpenFAST (in my use case, the IFX version of OpenFAST has faster computation speed).

To Reproduce
Steps to reproduce the behavior:

1. Compile openfast_x64.exe with IFX compiler in Intel oneAPI 2025.0.0 or 2025.0.1;
2. Run 5MW_OC3Mnpl_DLL_WTurb_WavesIrr with default settings.

Expected behavior
Memory usage does not increase significantly as the time-history analysis progresses when the binary is compiled with the IFX compiler.

OpenFAST Version
OpenFAST v4.0.0, git commit da685d4.

**************************************************************************************************
OpenFAST

Copyright (C) 2025 National Renewable Energy Laboratory
Copyright (C) 2025 Envision Energy USA LTD

This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.
**************************************************************************************************

OpenFAST-v4.0.0-dirty
Compile Info:
 - Compiler: Intel(R) Fortran Compiler 20250004
 - Architecture: 64 bit
 - Precision: single
 - OpenMP: No
 - Date: Jan 20 2025
 - Time: 12:41:32
Execution Info:
 - Date: 01/20/2025
 - Time: 20:27:12+0800

System Information (please complete the following information):

• OS: Windows 11 24H2
• Compilers:
  1. IFX compiler in Intel oneAPI 2025.0.0 (Intel(R) Fortran Compiler 20250000 in Compile info);
  2. IFX compiler in Intel oneAPI 2025.0.1 (Intel(R) Fortran Compiler 20250004 in Compile info).
• Compiler settings:
  1. Default compiler settings in Visual Studio .sln file for compilers (i)(ii), single precision;
  2. Change the optimization level to o3 for compiler (ii), both single and double precisions.

[deslaughter]

@Typhaceae Thank you for the bug report. Before I try to reproduce, could you tell me if you're running the model with binary output? If so, could you try running the model with text-based output and see if the increase in memory stops? When doing binary output, Fortran will allocate memory to store all of the output data at the beginning of the simulation, but the OS will only show that memory as being used as data is being written to it. I'm not saying this is the issue, but it's very easy to check before digging further.

[IrisMeasure]

@Typhaceae Thank you for the bug report. Before I try to reproduce, could you tell me if you're running the model with binary output? If so, could you try running the model with text-based output and see if the increase in memory stops? When doing binary output, Fortran will allocate memory to store all of the output data at the beginning of the simulation, but the OS will only show that memory as being used as data is being written to it. I'm not saying this is the issue, but it's very easy to check before digging further.

@deslaughter In fact, in my use case, I set OutFileFmt to 3, generate both text and binary files.
I just set OutFileFmt to 1, 2, and 3 respectively, and ran the openfast binaries compiled with two compilers (ifort_out, ifort_outb, ifort_both, ifx_out, ifx_outb, ifx_both).
Initially, the memory usage of all processes was 1494 MB. After the time-history analysis began, the memory usage of the process ifort_out changed to 1383MB, while the memory usage of processes ifort_outb and ifort_both changed to 1447MB. Meanwhile, the memory usage of the binary files compiled with ifx (ifx_out, ifx_outb, ifx_both) started to gradually increase.
All memory usage data was read from the Windows Task Manager.

Edited: For the case 5MW_OC3Mnpl_DLL_WTurb_WavesIrr, the phenomenon is similar.

[deslaughter]

@Typhaceae Thank you for the detailed test cases. I'm able to reproduce the increasing memory usage on Linux with ifx 2025.2. I'm running valgrind now and hoping that I can figure out where it's coming from.

[deslaughter]

@Typhaceae It looks like it's the HeapArrays option that's causing the memory leak. I've got a PR that's about to go in that disables that option in Visual Studio, but you're welcome to give it a try.

[andrew-platt]

This should be fixed with released 4.0.3