Calculate buoyancy for an MHK turbine

[hkross]

This pull request is ready to be merged.

Development is complete and all existing regression tests pass. New regression tests have been added, along with macOS-gnu baselines. Baselines from other compliers still need to be added. A corresponding pull request (#55) has been added to the r-test repository.

Feature or improvement description

This pull request allows buoyant loads on a marine hydrokinetic turbine to be calculated and adds the following features:

• Buoyancy parameters for the blade, tower, hub, and nacelle added to the AeroDyn blade and primary input files
• Buoyancy flag added to the AeroDyn primary input file
• Buoyant loads on the blade, tower, hub, and nacelle calculated in AeroDyn and added to existing loads
• Hub and nacelle loads passed to ElastoDyn (glue code changes for nacelle included in prior pull request)
• Outputs added for buoyant loads
• Outputs denoted as 'Aero' changed to 'Fld'

Impacted areas of the software

• AeroDyn module
• AeroDyn driver
• OpenFAST glue code

Test results

All existing regression tests have been updated and pass. New regression tests have been added, including input files and macOS-gnu baselines. Baselines from other compliers still need to be included.

Check list

• [x] Fix glue code bug (see section below)
• [x] Merge in #1009
• [x] Update docs/source/user/api_change.rst
• [x] Update documentation
• [x] Merge in #1078
• [ ] Add baselines for OpenFAST and AeroDyn driver fixed MHK regression tests (macOS-gnu already added)

Additional supporting information

Update: This bug was fixed by this pull request. There is a bug in the glue code changes that prevents test cases from converging when buoyancy is turned on. Cases only converge if all degrees of freedom are turned off in ElastoDyn (with the exception of the blades) or if the new code in FAST_Solver.f90 that transfers hub loads from AeroDyn to ElastoDyn is commented out (line 381).

[hkross]

I found the source of the instability in my test cases. I had not initialized u_ED%HubPtLoad%Force and u_ED%HubPtLoad%Moment to zero, so the hub buoyant loads were summed over time, leading to extremely large loads. I had previously initialized these variables to zero but removed this code during debugging, as it introduces another error. If u_ED%HubPtLoad%Force and u_ED%HubPtLoad%Moment are reset to zero at each time step in ED_InputSolve, errors arise in cases using BeamDyn, since these variables are also set in Add_FullOpt1_u_delta. It seems like Add_FullOpt1_u_delta uses the value at the previous time step, so reseting it to zero causes issues. I am not sure how to handle a case where buoyancy is turned on and BeamDyn is used. Should the buoyant loads be passed to the option 1 solve? @jjonkman and @andrew-platt, it would be great to have your input on this.

In my last commit, I set u_ED%HubPtLoad%Force and u_ED%HubPtLoad%Moment to zero in ED_InputSolve, which caused the 5MW_Land_BD_Linear regression test to fail.

[jjonkman]

I'm glad you found the problem, @hkross!

I expect the solution for how to transfer the AeroDyn loads to the ElastoDyn hub is similar to how the StC loads are transferred to the ElastoDyn platform (when SubDyn is disabled). Like the StC load transfer, the AeroDyn load transfer to the ElastoDyn hub is an Option 2 solve and the other contribution to the load (BeamDyn for the hub and HydroDyn for the platform) is solved in an Option 1 solve. I'll let @andrew-platt comment because he implemented the Option 2 solve for the StC loads transfer to the ElastoDyn platform.

[andrew-platt]

I think we sorted out the issue. The buoyancy loads are now applied in Option 2 solve when BD is not used, or in Option 1 when BD is used. This is a little simpler than how the SStC loads are transferred (those are routed either to ED%PlatformPtMesh, or to SD%Y1Mesh if SD is used).

This is currently in a PR to @hkross branch.

[hkross]

Thanks for your help, @jjonkman and @andrew-platt. I believe Andy's pull request fixed the bug with the loads transfer.

[ebranlard]

My small comments here would be:

• I've added some backward compatibility so that blade files without Buoyancy inputs can still be read
• I would be in favor of having the nacelle NacCenBx,y,z inputs to be on one line instead of 3
• I would place the Hub and Nacelle inputs above the tower, to have the inputs in that order: Blades > Hub > Nacelle > Tower

I'm eager to get this pull request in, so I can take care of some changes if needed.

[hkross]

My small comments here would be:

• I've added some backward compatibility so that blade files without Buoyancy inputs can still be read
• I would be in favor of having the nacelle NacCenBx,y,z inputs to be on one line instead of 3
• I would place the Hub and Nacelle inputs above the tower, to have the inputs in that order: Blades > Hub > Nacelle > Tower

I'm eager to get this pull request in, so I can take care of some changes if needed.

Thanks, @ebranlard. I can take of the input file changes for this if you can make the code modifications. Would that work?

[ebranlard]

No worries, I'm happy to do all of it. Do you think the changes would make sense? I'm waiting for @jjonkman feedback as well.

[hkross]

I am fine with either option for both the NacCenBx,y,z inputs and the order of inputs for the tower, hub, and nacelle. The main motivation for putting the hub/nacelle inputs after the tower was that hub/nacelle inputs are only relevant for MHK turbines, whereas the tower inputs are more generally used. So, it made sense to me to have them after the tower since they will more often be neglected. But, I am fine with having it either way.

[ebranlard]

I guessed so, in the future we can add aerodynamics loads on the nacelle, that's why I think it makes sense to have it higher up.

[ebranlard]

I will take care of the changes

[hkross]

I will take care of the changes

Thanks, @ebranlard. I can take care of the documentation changes @jjonkman suggested.

[hkross]

@ebranlard I changed a couple small things in the documentation. Otherwise, all the changes look good.