-
Notifications
You must be signed in to change notification settings - Fork 465
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
AeroDyn driver regression test case failing inconsistently #841
Comments
For reference, here's a compiler log of AeroDyn Driver with all compiler warnings enabled ( |
The combined case re-initializes AeroDyn, and perform several simulations. My guess is that it could be linked to some variables not being cleaned up/deallocated or reallocated. |
This type of syntax caused issues in some version of gfortran long ago: old-NWTC/NWTC_Library@976d9bd#diff-9cf80e40ecf0eacb20ef6f7042888d47defca409fb3c4bb7e972be47e93c2e6f Maybe this helps with OpenFAST#841?
In this case, the I updated some code just now so that we should not see the issue with accessing past the end of the |
@rafmudaf , I've been running these cases through Inspector to try to understand what's going on in these cases. In the MacOS with GCC 11 case, it seems like the issue could have been related to a couple of FileInfo variables that weren't deallocated between file reads when AD is restarted. I think I have fixed this issue--at least I have not seen it again--but I'd feel more confident if I could confirm the original problem was what I suspect. In the Ubuntu with GCC 10 case, it seems to be producing a seg fault on the first call to AeroDyn when it is reading airfoil files. I have put a lot of additional error checks in there, but it still seems to be failing intermittently. I'm going to step away from this issue for now. |
Guess I spoke too soon.... in my last commit, everything worked okay on the OpenFAST PR side, but the MacOS with GCC 11 case failed on my fork. Here's the error it gave this time:
It seems like those arrays in the FileInfo type have a problem... |
UPDATE: I resolved the issue with my branch. The error was caused by the fact that one of the turbines defined in this test case has zero blades, and I was defining the size of a variable based on the number of blades. This commit resolved the issue. I am not sure if this translates over to the other issues mentioned in this thread. I am seeing similars error on my Buoyancy feature branch. The
|
Hi Hannah, could you cherry-pick this commit and submit a pull request for your fix maybe? |
You mean the commit that fixes the allocation of |
Maybe I misunderstood, I thought you found a solution to this issue (#841), but your solution only works for the Buoyancy branch it seems. Sorry! |
Ah. Yes, unfortunately the issue I was seeing was within a buoyancy variable, so not applicable to dev. |
Unfortunately, the bug persists and its not captured in the tests. I had started to dig into this earlier in the year on a Linux computer, and after recompiling with the latest dev branch I am still able to trigger this issue by running the AD_BAR regression test cases in a loop: for i in {1..20}; do
echo $i
cd build/
if ! ctest -R ad_BAR -j8 ; then
cd ../
# cp -r build build_$i ## Save the failing build directory for further inspection
rm -rf reg_tests/modules/aerodyn
else
cd ../
fi
done |
Okay, thanks for the update. |
Bug description
The
ad_BAR_CombinedCases
AeroDyn module-regression test case is failing inconsistently in the GitHub Actions environment. In one case it fails on Ubuntu with GCC 10, and in another case it fails on macOS with GCC 11. Both of these are compiled in Debug mode. In Release mode, there is no error.The reported error is also different between jobs.
In the first, we see an error
Fortran runtime error: Index '1' of dimension 1 of array 'fileinfo%lines' above upper bound of 0
:In the other, a stack trace is not reported.
To Reproduce
I have not been able to reproduce this locally. On GitHub Actions, simple run
ctest -VV -j7 -R ad_
.It's compiled with the following CMake command:
OpenFAST Version
This is happening on commits on top of 0543df2
System Information (please complete the following information):
--coverage
flag--coverage
flagThe text was updated successfully, but these errors were encountered: