Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible memory leak #2613

Open
Typhaceae opened this issue Jan 22, 2025 · 3 comments
Open

Possible memory leak #2613

Typhaceae opened this issue Jan 22, 2025 · 3 comments

Comments

@Typhaceae
Copy link

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
Copy link
Collaborator

@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.

@Typhaceae
Copy link
Author

Typhaceae commented Jan 22, 2025

@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
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants