Skip to content
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

Tight Coupling Solver #1850

Closed

Conversation

deslaughter
Copy link
Collaborator

This pull request is not ready to merge. This PR has been opened to help users find the repo containing the new tight coupling algorithm. Development is ongoing.

Feature or improvement description

This PR implements the new tight coupling solver algorithm which significantly improves the speed of the solve when using BeamDyn and SubDyn.

Impacted areas of the software
The glue code has been changed significantly and mostly replaced. Modules have been updated to work with the new glue code.

Additional supporting information

Test results, if applicable
Test cases need to be updated.

deslaughter and others added 30 commits July 21, 2023 21:28
It was possible to use .false. and .true. for initial values, but these
are rather cumbersome in the registry file, so this short form
should make it easier without loosing clarity
Previously, Registry_NWTC_Library.txt had to be manually generated
by concatenating the mesh version and the base version. This makes
it automatic in CMake and generates the NWTC_Library_Types.f90.
This package manages module variables and values that are used by the
solver and linearization.
These changes add vars and vals to ED so the module can be used in
the tight coupling solver.
Using -DTIGHT_COUPLING=ON when configuring the project
will make it build with the tight coupling solver
These will need to renamed/merged
In the BeamDyn driver, and likely in the glue-code, if the blade was
initially rotated then an initial strain was introduced which produced
forces when no loads or gravity had been applied. The cause was
traced to the calculation of R0 (initial rotation) at the quadrature
points which was interpolated via the shape functions from the
element nodal rotations. The shape function interpolation is not
exact and introduced strains on the order of 1e-7, but with the large
stiffness of the blade, forces of 6200 N could be produced at the root
for the IEA 15MW blade. This was resolved by directly calculating
the quadrature point initial rotations in uu0(4:6) via interpolated
tangent and twist, which are well behaved. This was only a problem for
non-straight blades such as the IEA 15MW.

This commit also fixes a bug where the parameter UsePitchAct
wasn't initialized from the input file until after it was used in
SetOutParam. The initialization has been moved to SetParameters.
The reference frame is now moving.  All values from p%GlbRot, p%Glb_crv, and p%GlbPos are now stored as otherstates and get updated at the end of an updatestates routine.

Additional logic and data handling was changed within BD:
 - UpdateStates starts with the initial root position at T, and `q` and `dqdt` are relative to this position/orientation.
 - once UpdateStates converges, the `q` and `dqdt` states are updated to the root position/orientat at T+dt

 - Output calculations (mesh and channel outputs) have been modified
 - Inputs are slightly modified as well

During Init, the values in `q` and `dqdt` are updated twice.  The first time is relative to the reference frame for the meshes, and the second time for the mesh reference frame + displacements.
may have positions in mesh partially correct.  Rotations appear too far though, so something wrong with rotation handling
@deslaughter deslaughter self-assigned this Nov 2, 2023
@deslaughter deslaughter changed the title F/tightcoupling Tight Coupling Solver Nov 2, 2023
@andrew-platt
Copy link
Collaborator

andrew-platt commented Nov 2, 2023

As of the opening of this PR, the code is very much a work in progress. The input files in the regression test repository linked are not actually compatible with this PR as of Nov 2, 2023.

So attempt to use at your own peril. We'll post an update when there are input files that work with this PR available.

@deslaughter
Copy link
Collaborator Author

Decided to rebase this PR on a new branch since it had diverged so much from dev-unstable-pointers. Will open a new PR with that branch when ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants