[BugFix] BD: variable passing in Calc_RR0mEta_rho #2642
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The argument RR0mEta to Calc_RR0mEta_rho was handled inconsistently. See issue OpenFAST#2641 for details
Collaborator
Author
|
deslaughter
reviewed
Feb 18, 2025
andrew-platt
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ready to merge
Feature or improvement description
In the
BD_Calc_RR0mEta_rhoroutine, theRR0mEtaoutput was not getting set, but instead them%qp%RR0mEtawas set directly. However theRR0mEtavalue was passed out of the routine directly tom%qp%RR0mEta, so it becomes ambiguous if the compiler would set that value through the routine, or set it to the uninitialized value ofRR0mEta.Related issue, if one exists
Issue #2641 outlines the issue in more detail.
Impacted areas of the software
BeamDyn, but likely only with specific compilers (most seem to handle this odd code).
closes #2641