Added n_nodes to all input functions for the models

[TheMercer]

Maybe add n_nodes as input to all tower reading functions
Also add n_nodes as input to all blades reading functions

From_windio_floating doesn't have it. Limitation and check other functions

This will mean it's same logic across all.

Thank you for all the updates so far

[SMI-Lab-Inha]

Partial update on this — the geometry/ontology constructors now have a uniform n_nodes/n_span surface, which was the immediate gap you flagged (from_windio_floating didn't have it). The deck/BMI readers are intentionally left out for now; rationale below.

Shipped (merged to master, ships in the next release)

• Tower.from_windio_floating(..., n_nodes=N) — re-grids the tower beam onto N evenly-spaced stations (geometry linearly interpolated, closed-form tube properties recomputed exactly), exactly like Tower.from_windio / Tower.from_geometry. The platform assembly is untouched. Additive, non-breaking (default None keeps the WindIO grid).

So the synthesizing constructors are now consistent:

Constructor	mesh-refinement kwarg
Tower.from_geometry	n_nodes ✅
Tower.from_windio	n_nodes ✅
Tower.from_windio_floating	n_nodes ✅ (new)
RotatingBlade.from_windio	n_span ✅

Deferred (and why) — the deck/BMI readers

from_bmi, from_elastodyn, from_elastodyn_with_subdyn/_with_mooring, and RotatingBlade.from_elastodyn are not getting n_nodes in this change. They're a different kind of input: they read a deck that already carries an explicit discretization and tabulated section properties. The synthesizing constructors above build the mesh from continuous geometry, so re-gridding is exact (recompute closed-form tube properties at each new station). For a deck, n_nodes would instead resample already-tabulated properties onto a new grid — lossier, and it would silently smooth a deliberately stepped deck (e.g. a wall-thickness jump), which is a real footgun. That deserves to be an opt-in feature with the smoothing behaviour clearly documented, not a blanket addition that quietly changes results.

Leaving this issue open to track the deck-reader half. If you have a specific deck path where you want mesh refinement, tell me which one and the geometry you're feeding it, and I'll scope it with the resampling caveat surfaced explicitly. Thanks again for the consistency nudge — it's a good one.