AeroAcoustics improvements - #3449
Conversation
Debug build does not work without this. FFTPACK relies on some old Fortran method of passing the different datatypes through the same interface. Note: this also reorders some files that were added out of alphabetical order. This prevents VS from giving differences every time the file is open (though it doesn't fix the problem with the registry files in the VS project)
We noticed a couple of spikes that occurred in AA output files during a simulation, but when re-run with the same executable and same input files, the spike disappeared (all non-AA outputs were the same). I asked AI to take a look at the code for uninitialized variables and other memory issues in the AeroAcoustics module, and it came back with these changes. Note the warning about re-entrant code in TNO Assisted-by: Kiro:claude-opus-5
The AA driver allows only one node for testing purposes, but if the BldPrct isn't 100 in that case, it would ALWAYS give a warning about changing the aerodynamic mesh. This check avoids printing the message in that case. Assisted-by: Kiro:claude-opus-5
In the future, we can upload steering that is more general, but for now, I'm ignoring my .kiro files.
Make sure the 10^x calculations don't overflow. All 10**(x) calculations have been replaced with Power10AA(x), which makes sure the exponent doesn't get larger than new variable AA_max_exp.
in case U < 0, we want to make sure that the Reynold's Number and Mach Numbers are positive
- Added a warning message if we ever end up with overflow, which indicates the noise predictions are unrealistically large. - Made `Unoise` be a positive value. It's used for Reynolds Number, Mach Number, and Strouhal Number. Making it the absolute value avoids having to add abs() around 7 more lines of code. - fixed initialization of LogVal in the Blunt routine, which I had erroneously added in a previous commit Assisted-by: Kiro:claude-opus-5
the vs-build/.gitignore was removed and these entries would be lost
| ! functions f_int1/f_int2/Pressure receive their parameters, because slatec_qk61 only accepts a function of one | ||
| ! variable. SPL_integrate() sets all of them on entry, so sequential calls (including calls for different rotors or | ||
| ! different blade nodes) are safe. This module is NOT reentrant, however: it must not be called from more than one | ||
| ! thread at a time, or one thread will overwrite another thread's flow conditions mid-integration. |
There was a problem hiding this comment.
Does this have implications on using AA with FAST.Farm?
There was a problem hiding this comment.
Possibly. It's global data that is used in place of sending variables through subroutine arguments. If two threads are using/changing it at the same time, that would be a problem.
It looks similar to the way AeroDyn used to implement the sub_brent method. We later simplified the logic to avoid those global variables. This would probably be a fairly straightforward task for AI. If I get some time to come back to this, maybe I'll take a second look.
There was a problem hiding this comment.
If it is really easy, it's worth doing now. However I suspect it isn't a feature that gets used with FF (separate OF instances won't be additive at a given location).
|
Thanks for addressing the problematic math @bjonkman! |
|
I'm very confused on why some linearization tests are failing. I wouldn't expect any of this code to by used in those cases ( edit: after multiple reruns it succeeded. This is not due to this PR, but a systemic issue with those cases. We'll have to look into that separately later. |
This replaces the NWTC_SLATEC.f90 code with an integration scheme that is reentrant. Global variables are replaced with subroutine arguments stored in a data type. Assisted-by: Kiro-claude-opus-5
2 participants
Feature or improvement description
This pull request primarily addresses potential numerical issues in the aeroacoustics module. There are now safety checks around negative Reynolds, Mach, and Strouhal Numbers, overflow with 10^x, and division-by-zero. Some variables that may have been uninitialized are now set.
It also
Related issue, if one exists
Impacted areas of the software
Aeroacoustics, VS build
Additional supporting information
We have noticed at least one instance where the AA module output a large spike, which disappeared when re-run with the same executable and input files. I can't yet confirm if these changes fixed the issue, but I am hopeful that it helped.
Generative AI usage
Assisted by: Kiro:claude-opus-5
Test results, if applicable