[FEATURE] Tower material properties override

[TheMercer]

What problem does this solve?

This allows you to override the input file, for given material properties. Allows for sensitivity studies to be done directly in pyBmodes

Proposed API or behaviour

In windio functions, allow override for tower properties ?        
        E: float = 2.0e11,
        rho: float = 7850.0,
        nu: float = 0.3,
        outfitting_factor: float = 1.0

Maybe could do the same for Monopile struct props

Citable references

No response

Alternatives you've considered

No response

Scope estimate

None

Anything else?

No response

[SMI-Lab-Inha]

Good idea, and this is a sensible non-breaking addition.

One thing that already works today, so you are not blocked in the meantime. Tower.from_geometry takes all four as keywords, so if you drive a sensitivity study from the tube schedule you can sweep them directly.

Tower.from_geometry(station_grid, outer_diameter, wall_thickness,
                    flexible_length=..., E=2.0e11, rho=7850.0, nu=0.3,
                    outfitting_factor=1.0, tip_mass=rna)

What is missing is the same override on the from_windio / from_windio_with_monopile path, where the material currently comes only from the ontology materials block. I will add optional E / rho / nu / outfitting_factor keywords there that, when given, take precedence over the ontology value for the tower (and the monopile on the combined path), defaulting to the ontology so nothing changes for existing callers. That gives you the sensitivity sweep straight off a WindIO file without editing the yaml.

I will track it for the next minor release. If you want it to also cover the composite blade material on RotatingBlade.from_windio, say so and I will scope that separately, since a blade layup carries per-layer materials rather than a single tower-wall steel.

[SMI-Lab-Inha]

Done, this is on master now and ships in the next release.

Tower.from_windio and Tower.from_windio_with_monopile take optional E, rho, nu and outfitting_factor. Each defaults to None, meaning use the ontology value, so nothing changes unless you pass one.

# sweep straight off the WindIO file, no yaml edits
Tower.from_windio(yaml, E=1.9e11, outfitting_factor=1.0)
Tower.from_windio(yaml, rho=8050.0)

On the combined monopile+tower path the override is applied to both segments, so a single value drives a whole-structure sweep. For different materials per segment, edit the ontology instead. Thanks for the suggestion.