Discrepancies in onshore/monopile tower definition and input files

[jennirinker]

Description

Short summary: In fall of 2021, the yaml points defining the tower model were smoothed out and changed. This not only removed stepwise values in the thickness that were present in the original design but also changed the tower definition itself. @gbarter is in agreement with me that the tower thickness should be stepwise, but I am awaiting confirmation of whether the thickness should also be reverted to the original design. (Update: Confirmed; see comment below.)

Furthermore, HAWC2 matches the existing yaml but OpenFAST does not (see below).

Impact

Going purely off the yaml alone (i.e., ignoring the HAWC2/OpenFAST implementations), the tower mass WITHOUT the transition piece is:

• Per original design report: 760 t
• In current yaml file (no stepwise values): 854 t
• With the design as specified in the original report: 853 t

I do not know why the tower mass in the original report is so much lighter than the values I calculate, unless there was a typo and the value in the report is without the transition piece. Even assuming that, the tower mass would still be off by 6 tons, reason unknown.

General notes

• This is related to #116
• The commit where we got changes in the stepwise thickness was 8fbf3fc61890af4986803a5b3a1587401c8e337a
• I would need to check/update the yaml, the OpenFAST values, the HAWC2 values, and the Excel.

[jennirinker]

Some more documentation.

Here is a comparison of the current yaml file with what was in the original report:

From this, it looks like the yaml points were calculated by linearly interpolating the existing discrete points.

Here is a comparison of the HAWC2/ElastoDyn models with the yaml. HAWC2 matches the yaml, ElastoDyn does not. Neither of them match the original design.

[jennirinker]

@gbarter I would like to start a PR that:

• changes the tower definition in the yaml back to the definition in the original report
• updates the HAWC2/OpenFAST models to match this definition
• Adds a new test -- exact nature TBD
• [optional] updates the Excel documentation to match this interpretation
• [optional] adds some documentation explaining how the tower is interpreted/defined from the yaml

(Note that I would probably not be the person updating the OpenFAST model and the Excel file, as I think these are done via WISDEM tools.)

Would that be okay with you? Anything you would prefer instead?

[gbarter]

@jennirinker - This is an awesome display of Github communication prowess! Yes, of course it is okay to open a PR to restore the files to their current design intent. I am certainly guilty of some hubris here in that 2021 change you mentioned went forward because WISDEM continued to interpret the tower the same way with the revised yaml, but none of the other codes did. Thank you for both documenting the issue and offering to correct my errors.

Most of our CI checks ensure that things run, and a couple of them check that OF and HAWC2 are equivalent. We may want to think about a new test for the tower, or maybe a regression test in some way.

[jennirinker]

@gbarter Thank you for the compliment! I'm trying to be exemplary for this repo to save you from answering the same question a thousand times haha.

I love the idea of the new test -- I updated the list above to include it. In the PR we'll have to align on exactly what we want that test to look like. I have a few ideas, but some might be more troublesome than others.

I'll go ahead and start the PR over the course of the week, but it will be a WIP because I'll have to rebase off the 1.15 release before we can merge it.