Fix for linear trim solution #1158
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
- Changed name of optional parameter in`ModName_GetOP` routine from `NeedLogMap` to `NeedPackedOrient` in an attempt to clarify what that does (returns the orientation matrix as a 3-valued vector instead of 9-valued one) - Made the use of this value consistent in ElastoDyn (all meshes with orientation fields that are packed in the GetOP routine need to have the same value for their call to `PackMotionMesh`) - Added the optional `NeedPackedOrient` input to `SD_GetOP` - Made ED, BD, and SD each pack their arrays the same way in `FAST_DiffInterpOutputs`; otherwise, the linear trim solution does not difference all of the outputs correctly to determine if it has converged
andrew-platt
approved these changes
Jul 11, 2022
bjonkman
added a commit
to bjonkman/openfast
that referenced
this pull request
Oct 6, 2022
- The operating point used for trim solutions cannot use GetSmllRotAngs since we can't assume all angles in the simulation are less than 25 degrees. It reverted back to log maps for this calculation. - I removed the rotational accelerations from the packed arrays for trim solution. These can be noisy outputs, and we are already making sure that the position and velocity values are converging. - I updated the argument names in the `GetOP` routines for the structural codes that output motions. This is a follow-up to OpenFAST#1158.
bjonkman
added a commit
to bjonkman/openfast
that referenced
this pull request
Oct 6, 2022
- The operating point used for trim solutions cannot use GetSmllRotAngs since we can't assume all angles in the simulation are less than 25 degrees. It reverted back to log maps for this calculation. - I removed the rotational accelerations from the packed arrays for trim solution. These can be noisy outputs, and we are already making sure that the position and velocity values are converging. - I updated the argument names in the `GetOP` routines for the structural codes that output motions. This is a follow-up to OpenFAST#1158.
ebranlard
pushed a commit
that referenced
this pull request
Oct 7, 2022
- The operating point used for trim solutions cannot use GetSmllRotAngs since we can't assume all angles in the simulation are less than 25 degrees. It reverted back to log maps for this calculation. - I removed the rotational accelerations from the packed arrays for trim solution. These can be noisy outputs, and we are already making sure that the position and velocity values are converging. - I updated the argument names in the `GetOP` routines for the structural codes that output motions. This is a follow-up to #1158.
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.
Feature or improvement description
This PR makes the linearization trim solution treat orientations consistently and fixes how the orientations were output in the SubDyn operating point portion of linearization output files. I also changed parameter names in
ModuleName_GetOPto hopefully make their intent clearer.I am not convinced that the
PackMotionMeshroutine should be using small rotational angles instead of log maps. It is unclear to me why log maps can be used in the angle extrapolations in registry-generated files, but not allowed inPackMotionMesh, which is used in a similar way to get differences in angles in the trim solution. However, for now, I will leave that discussion up to the people who originally changed that part of the code in #1050.Related issue, if one exists
#1050
Impacted areas of the software
Additional supporting information
The modules that have motion meshes as outputs and are part of the linearization solution (ED, BD, SD) need to have their orientations packed as a 3-valued array instead of the 9-valued orientation matrix in the calls to
ModName_GetOPin the trim solution so that we can make sure they converge. In #1050, some of this got modified inconsistently: some of ED's fields were 9-valued orientations and some were 3-valued arrays; all of BD's orientations were 9-valued arrays. This resulted in the trim solution not checking that all of the output values converged but also trying to make sure all 9 components of many orientation matrices converged (instead of just the 3 angles they represent).The modules'
ModName_GetOProutine should return the 9-valued orientation matrix for operating-point output in the linearization output files. In SubDyn, this always returned a 3-valued vector, which would have made the operating points printed incorrectly in the linearization output files (and possibly seg fault).Test results, if applicable
I don't think there are any tests for the linearization output files or for the trim solution.