Remove QuKi (quad-precision) from OpenFAST. #1453
Merged
Conversation
This file contains 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
This commit removes quad-precision kind, QuKi, from OpenFAST. As such: - DbKi = real64 - R8Ki = real64 - SiKi = real32 - ReKi = real64 if DOUBLE_PRECISION else real32 Routines which used QuKi (R16) in generic interfaces have been removed. The compiler flagss have been modified to set the default real to 8 bytes and the default double to 8 bytes when DOUBLE_PRECISION is on. This change should improve type clarity and remove the dependency on software implemented quad-precision floating point numbers. The UnsteadyAero unit test results were updated as the test wrote uninitialized values to the output file. This has been corrected by initializing members of the UA_KelvinChainType structure to 0.0.
- change `DBLE` to REAL(*,R8Ki) - remove QuKi from rest of the Sys*.f90 routines - make default double 64 instead of 128 in VS project files DP configurations - consistent variable types in `DCM_expR` and `DCM_SetLogMapForInterpR`and other routines in NWTC_Num.f90
More updates for new `DbKi=R8Ki` behavior
andrew-platt
approved these changes
Feb 27, 2023
This fixes an issue in the UnsteadyAero regression test
bjonkman
reviewed
May 8, 2023
| @@ -60,18 +57,18 @@ MODULE Precision | |||
| INTEGER, PARAMETER :: IntKi = B4Ki !< Default kind for integers | |||
| INTEGER, PARAMETER :: BYTES_IN_INT = 4 !< Number of bytes per IntKi number - use SIZEOF() | |||
|
|
|||
| #if !defined (DOUBLE_PRECISION) && !defined (OPENFAST_DOUBLE_PRECISION) | |||
There was a problem hiding this comment.
Removing this DOUBLE_PRECISION preprocessor definition check made the vs-build project files not able to build in double precision any more. (Notice that the new code checks only for OPENFAST_DOUBLE_PRECISION). I am adding a fix for this in #1008, but maybe we need to update documentation, too? See the original reason for the two preprocessor definitions here: #524
There was a problem hiding this comment.
@deslaughter, can you take a look at this? I think we need to fix it for 3.5.0
There was a problem hiding this comment.
@bjonkman, could I change the vs-build project files to define OPENFAST_DOUBLE_PRECISION instead of DOUBLE_PRECISION?
There was a problem hiding this comment.
@deslaughter You can cherrypick this commit with the changes to the vs-build files: 9787e50 Hopefully I got them all.
bjonkman
added a commit
to bjonkman/openfast
that referenced
this pull request
May 8, 2023
…SION` This backward-compatibility of preprocessor definitions from OpenFAST#524 was broken in OpenFAST#1453.
deslaughter
pushed a commit
to deslaughter/openfast
that referenced
this pull request
May 8, 2023
…SION` This backward-compatibility of preprocessor definitions from OpenFAST#524 was broken in OpenFAST#1453.
deslaughter
added a commit
to deslaughter/openfast
that referenced
this pull request
May 8, 2023
…SION` This backward-compatibility of preprocessor definitions from OpenFAST#524 was broken in OpenFAST#1453.
deslaughter
added a commit
to deslaughter/openfast
that referenced
this pull request
May 8, 2023
This backward-compatibility of preprocessor definitions from OpenFAST#524 was broken in OpenFAST#1453.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This pull request is ready to be merged.
Feature or improvement description
The changes in this pull request remove the quad-precision (QuKi) from OpenFAST. When the
DOUBLE_PRECISIONCMake option was set toON, it causedReKireals to be promoted toreal64precision (double) andDbKireals to be promotoed toreal128(quadruple precision). Some architectures and compilers do not support quadruple precision (Flang) which caused issues with compiling. In addition, using quad-precision numbers is significantly slower because operations are typically implemented in software instead of in hardware. This change had negligible effects on the linearization regression test outputs (minor fluctuations in numbers near zero).Related issue, if one exists
Impacted areas of the software
NWTC Library had the most modifications where all uses of QuKi and associated routines were removed.
HydroDyn Driver: changed dcm from R8Ki to ReKi to match main HydroDyn code and resolve issue with generic interface.
UnsteadyAero: discovered that the reference output in the unit test had uninitialized data in the first time step because it wrote several members of the KC (UA_KelvinChainType) before they had been set. Modified the registry file to provide initial values for all members of the structure (0.0).
Additional supporting information
Test results, if applicable
Updated unit test reference results for the UnsteadyAero_Driver. Branch created in r-test which will need to be merged into dev. All other tests pass.