Tower input

[TheMercer]

Could it be done so that if you like and only know geometric properties and not independently calculated the tower structure properties.

That either allow BMI for tower to define outer diameter and inner diameter or outer diameter and thickness.

Also point masses along the tower (account for internals/ flanges etc) ?

Then have the tool, calculate all structural properties automatically instead of user error.

[TheMercer]

WindIO input, would have tower geometry + would have the blade stiffness that's also needed for a full system.

[SMI-Lab-Inha]

Status (as of v1.4.1) — partially delivered; kept open for the remaining sub-item.

Delivered & validated

• Auto-derive all structural properties from tube geometry — Tower.from_geometry(station_grid, outer_diameter, wall_thickness, *, flexible_length, E, rho, nu, outfitting_factor). Closed-form circular-tube reduction; reproduces the WISDEM-generated IEA-15 ElastoDyn tower table to 7.5e-12 (machine precision). Eliminates the hand-computed-properties error class this issue asked about. (OD+ID is the same datum as OD+thickness: t = (OD - ID)/2.)
• WindIO input with tower geometry + blade stiffness for a full system (per @TheMercer's clarification) — Tower.from_windio, RotatingBlade.from_windio (composite layup -> beam, BeamDyn-6x6-validated), Tower.from_windio_floating, and the one-click pybmodes windio orchestrator (blade + tower + coupled platform + report).
• Distributed non-structural mass (paint/bolts/internals, smeared) via outfitting_factor; the tower-top lump via tip_mass.

Gated by tests/test_geometry_windio.py, tests/test_windio_blade.py, tests/test_windio_floating.py, tests/test_windio_cli.py; tabulated in VALIDATION.md.

Remaining (why this issue stays open)

Discrete point masses at arbitrary tower heights (e.g. individual flanges / platforms / internals as concentrated lumps, not smeared) are not yet in the FEM mass assembly — see the explicit note at src/pybmodes/models/tower.py:302. outfitting_factor only covers the distributed approximation.

Planned resolution (validation-bar, not a rhetorical close)

A bounded additive extension: lumped translational mass added to the bracketing FEM nodes (linear weights, mass + first-moment conserving), default-off so existing behaviour is byte-identical. Validation anchor already in-suite: a point mass placed at the tip must reproduce the Blevins/Karnovsky concentrated-tip-mass frequency equation (tests/fem/test_uniform_tower_analytical.py), plus a base-mass null check and a mid-span Rayleigh monotonicity bound, run through the full default+integration ladder. This issue will be closed only when that lands and passes the bar.

[TheMercer]

Could you give example code.

How you would input blade and tower form WindIO, but floating properties hardcoded or bmi formate?

I like being able to get floating properties from WindIO, which you have implemented but alot of floater design is done separately. So how would you input the floating properties separately to the tower and blades geometry

[SMI-Lab-Inha]

@TheMercer — worked code for "blade + tower from WindIO, floating properties supplied separately". Three ways, all in v1.4.2:

1. Floater delivered as separate OpenFAST decks (validated, recommended)

The usual separate-floater deliverable (HydroDyn/WAMIT + MoorDyn + ElastoDyn platform):

from pybmodes.models import RotatingBlade, Tower

fowt = Tower.from_windio_floating(
    "turbine.yaml",                              # tower geometry (WindIO)
    hydrodyn_dat="floater/HydroDyn.dat",         # separately-designed floater
    moordyn_dat ="floater/MoorDyn.dat",
    elastodyn_dat="floater/ElastoDyn.dat",
)
res   = fowt.run(n_modes=12)                      # surge/sway/heave/roll/pitch/yaw + tower
blade = RotatingBlade.from_windio("turbine.yaml").run(n_modes=8)

With all three decks this is byte-identical to the BModes-JJ-validated from_elastodyn_with_mooring (~0.0003 %), only the tower is the machine-exact WindIO one.

2. Floater as hardcoded 6×6 properties — new in 1.4.2 (your "hardcoded" case)

When the floater team gives you raw matrices (a frequency-domain tool / WAMIT export / a published table):

import numpy as np
from pybmodes.models import RotatingBlade, Tower
from pybmodes.io import PlatformSupport          # now exported from pybmodes.io

ps = PlatformSupport(
    draft=-20.0, cm_pform=-14.94, mass_pform=1.78e7,
    i_matrix=np.diag([1.78e7, 1.78e7, 1.78e7, 1.25e10, 1.25e10, 2.37e10]),
    ref_msl=15.0,
    hydro_M=A_inf_6x6,        # infinite-frequency added mass (your tool)
    hydro_K=C_hst_6x6,        # hydrostatic restoring (your tool)
    mooring_K=K_moor_6x6,     # linearised mooring stiffness (your tool)
    distr_m_z=np.zeros(0), distr_m=np.zeros(0),
    distr_k_z=np.zeros(0), distr_k=np.zeros(0),
)
fowt  = Tower.from_windio_floating("turbine.yaml", platform_support=ps)
res   = fowt.run(n_modes=12)
blade = RotatingBlade.from_windio("turbine.yaml").run(n_modes=8)

Tower geometry from WindIO; floater taken verbatim from ps. Nothing about the substructure is read from the yaml or any deck. Mutually exclusive with the deck args (clear ValueError); optional rna_tip=TipMassProps(...) for the tower-top RNA lump. It feeds the same BModes-JJ-validated free-free FEM (OC3 Hywind ≈ 0.0003 %) — a regression test asserts byte-equivalence to building the BMI by hand, so this path adds no new numerics.

3. Whole system as a .bmi deck

If the entire tower+platform is authored as a BMI (tower beam + tow_support=1 6×6 block, like the bundled OC3Hywind.bmi): Tower.from_bmi("system.bmi") — fully supported, but then the tower is from the BMI, not WindIO. Use (2) to keep the tower from WindIO and inject the platform.

---

#35 status: the principal ask (auto-derive tower structural properties from geometry; WindIO tower + blade full system) was delivered in 1.4.x; the separate-floater input you asked about is now delivered (1.4.2, above). Kept open for the one remaining sub-item from the original post — discrete point masses at arbitrary tower heights (flanges/internals as concentrated lumps) — which is still a documented FEM gap (outfitting_factor only covers the smeared approximation) with the validation-bar plan posted earlier. It closes when that lands and passes the bar.

[TheMercer]

For from_WindIO or maybe in general for the tower and blade.

Maybe have it you can ask for how many nodes. so then you interp the properties ?

So currently the BMI has 10 tower nodes. I want 20 you split the 0 to 1 evenly. interp the values between/

This will help smooth higher mode shapes also

[TheMercer]

Also could you add

rna_tip as input to Tower.from_windio(...)

as currently I have to do

tower = Tower.from_windio(r"IEA-15-240-RWT_VolturnUS-S.yaml")         # or Tower.from_bmi("my_tower.bmi")
tower._bmi.tip_mass = rna_mass

which could be like

tower = Tower.from_windio(r"IEA-15-240-RWT_VolturnUS-S.yaml", tip_mass = rna_mass)         # or Tower.from_bmi("my_tower.bmi")

Which is clean and is what the .from_windio_floating does this is probably needed for from geometry also