Open jennirinker opened 1 year ago
This is also relevant for the monopile. Values from the yaml:
s [m] OD [m] t [mm]
0.000 10.0m 55.3mm
45.000 10.0m 55.3mm
45.001 10.0m 55.3mm
55.000 10.0m 55.3mm
55.001 10.0m 47.7mm
65.000 10.0m 47.7mm
...
Values from the Excel:
-75 10 55.341
-30 10 55.341
-29.999 10 55.341
-20 10 55.341
-19.999 10 51.509
-10 10 51.509
...
I agree that the YAML and Excel should be the same to avoid confusion. I think the Excel is currently carrying with it some WISDEM-specific assumptions about tower manufacturing. Essentially, WISDEM assumes a constant plate thickness for a tower section because you typically roll a flat plate trapezoid shape to make a conical section. So, along the tower height, you can have linearly varying diameter that change slope at the nodes in the yaml file, but are stuck with jumps in piecewise-constant thickness. To resolve this, WISDEM assumes that the constant plate thickness of a tower section is the average of the values at the yaml nodes: 51.5 = (55.3+47.7)/2. We could have easily just taken the first value as the constant for the next section and ignored the last value. Hopefully I'm making sense here.
On one hand, this is an assumption that is unique to WISDEM and shouldn't be in the reference model, on the other hand it does seem realistic as having a linearly varying thickness profile along the tabulated values is difficult to achieve in practice.
I am open to suggestions about how best to move forward.
I agree that the YAML and Excel should be the same to avoid confusion. I think the Excel is currently carrying with it some WISDEM-specific assumptions about tower manufacturing. Essentially, WISDEM assumes a constant plate thickness for a tower section because you typically roll a flat plate trapezoid shape to make a conical section. So, along the tower height, you can have linearly varying diameter that change slope at the nodes in the yaml file, but are stuck with jumps in piecewise-constant thickness. To resolve this, WISDEM assumes that the constant plate thickness of a tower section is the average of the values at the yaml nodes: 51.5 = (55.3+47.7)/2. We could have easily just taken the first value as the constant for the next section and ignored the last value. Hopefully I'm making sense here.
On one hand, this is an assumption that is unique to WISDEM and shouldn't be in the reference model, on the other hand it does seem realistic as having a linearly varying thickness profile along the tabulated values is difficult to achieve in practice.
I am open to suggestions about how best to move forward.
Hi @gbarter, So what you are saying in this message is that we could change the thickness value at the tower start (height=15 m) from 41.058 to 39,496, right?
Thank u
Maybe I don't understand the question fully. The tower base has a thickness of 39.496mm from here. The monopile top has a thickness of 41.058mm from here. The reference turbine does not have a detailed design of a transition piece which would couple those two.
The comment of piecewise-constant vs linear taper of thickness was along the tower or along the monopile, not at the interface between the two.
Description
The parameters listed in the "Tower Properties" tab on the Documentation tabular Excel don't match the values in the IEA-15-240 yaml file. For example, here is what I have from the yaml after adding extra values for discretization (it starts from 0 instead of 15, sorry...):
versus the Excel:
Steps to reproduce issue
I've pushed branch
tower_monopile
. There I modified the tower script in the HAWC2 fixed-bottom folder so it (1) properly accounts for the discretized tower properties and (2) cross-references with the Excel sheet to see if there are discrepancies. It makes some nice plots too -- could be useful to see why OpenFAST properties don't match with HAWC2. Note the branch is a WIP, as I'm hoping to get a draft of the monopile included soon (fixed at mudline, no soil model yet).Current behavior
The Excel and yaml don't seem to be synchronized.
Expected behavior
I would expect the Excel and yaml to be synchronized.
Code versions
[irrelevant]