[BUG] Tower delta freq on clamped

[TheMercer]

pyBmodes version

1.60.1

Python version

3.11.18

How did you install pyBmodes?

pip install pybmodes (from PyPI)

Operating system

Windows

What happened?

issue 128

Thanks for the props, that let me pin it down exactly, and it turns out to be a modelling-setup difference rather than a solver bug.

The whole ~3.3 % is the tower outfitting factor. Your ontology carries outfitting_factor: 1.07 on the tower, and pyBmodes applies it as a non-structural mass smear (paint, bolts, flanges, internals), so the tower is 7 % heavier and about √1.07 ≈ 3.4 % lower in frequency. Running your exact tower geometry (z 15 → 144.386 m, the OD / wall schedule you posted) with E = 200 GPa steel:

outfitting_factor | pyBmodes f₁ -- | -- 1.0 | 0.8010 Hz (matches your OrcaFlex 0.79959) 1.07 | 0.7743 Hz (matches your pyBmodes 0.7732)

The ratio is exact: 0.79959 / 0.7732 = 1.034 = √1.07. So the two models simply carry a different tower mass. Your OrcaFlex tower is the bare steel tube; pyBmodes includes the 7 % outfitting the ontology asks for.

To compare like for like, either add the 7 % non-structural mass to the OrcaFlex tower, or drop the outfitting from the pyBmodes side (set outfitting_factor: 1.0 in the ontology, or build the tower via Tower.from_geometry(..., outfitting_factor=1.0), which takes it as a keyword). Both land within a fraction of a percent then.

Closing as a setup difference, but reopen if the reconciliation does not come out as above and I will dig further.

What did you expect?

Pybmodes still produces

No Monopile just tower, TWR frequencys
Pybmodes produces 0.2437Hz (outfitting 1.07)
Pybmodes produces 0.2444 Hz (outfitting 1.00)
OrcaFlex prodcues 0.22599 Hz (I took RNA from pybmodes and put on top of PyBmode tower)

To reduce deltas between software

Delta of 7.87%, 8.2% respectively

Minimal reproducer

N/A

Traceback or unexpected output

N/A

Anything else?

No response

[SMI-Lab-Inha]

Thanks for the clean numbers. I rebuilt your exact case (the #128 tower geometry, clamped at the z=15 base, with the RNA assembled from the hub/nacelle/blade blocks you posted) and I reproduce your pyBmodes side to the digit.

outfitting	pyBmodes f1	you reported
1.07	0.2437 Hz	0.2437 Hz
1.00	0.2444 Hz	0.2444 Hz

So the pyBmodes side is confirmed, and this one is not the mass-setup story from #128. The gap to your OrcaFlex 0.22599 Hz is real and it is a fidelity difference, so let me be straight about where it comes from.

pyBmodes solves a linear Euler-Bernoulli modal eigenproblem with no gravity. OrcaFlex does a nonlinear static solve under gravity and then linearises about the deflected, preloaded state with Timoshenko (shear-flexible) elements. On a 129 m tower carrying a ~945 t RNA whose centre of mass sits ~4.6 m above the tower top, three effects that OrcaFlex keeps and pyBmodes drops all push the OrcaFlex frequency down.

1. Gravitational geometric softening. The tower self-weight plus the RNA weight put the tower in compression, and the elevated RNA acts as a mild inverted pendulum. I computed this from the mode shape for your case and it is about 2 percent, taking pyBmodes from 0.2437 to roughly 0.238 Hz. So gravity explains about a third of your gap, not all of it.

2. Shear flexibility. pyBmodes is Euler-Bernoulli, so it has no shear deformation. Your tower is 10 m in diameter over the lower span, which is stocky enough that Timoshenko shear knocks another couple of percent off the first mode. OrcaFlex includes it, pyBmodes does not.

3. The nonlinear preloaded state and how the RNA is attached. OrcaFlex linearises about the gravity-deflected shape, and the answer is sensitive to exactly how the RNA is rigidly connected above the tower top. I cannot separate this part without your OrcaFlex model.

Stacked up, a first-mode frequency that reads a few percent high against a nonlinear tool is the expected behaviour for a linear modal solver on a heavily topped tower, and the ~8 percent here is on the high side of that but in the right family.

Two quick tests would let us close it precisely, in the spirit of the outfitting reconciliation from #128:

• Turn gravity off in OrcaFlex (or set g=0) and re-run the modal. It should rise by about 2 percent toward pyBmodes. That isolates term 1.
• Tell me the OrcaFlex tower element type (whether shear is on) and how the RNA is attached (rigid link length, at the CM or the tower top, and whether the base is a true fixed constraint). That pins terms 2 and 3.

I want to be upfront that this is a genuine scoped limitation on the pyBmodes side, not just a setup mismatch. The linear, gravity-free, Euler-Bernoulli model is exactly what ElastoDyn assumes for its tower mode-shape polynomials, which is the design point, but it does mean the absolute frequency will sit a few percent above a nonlinear hydro-elastic tool once a heavy RNA is on top. I will note that limitation in the docs, and adding an optional gravity geometric-stiffness term for the tower is a tractable feature I am happy to look at if it would help your comparisons. Leaving this open for the two tests above.

[TheMercer]

99-105-Theoretical-results.pdf

Beam theory orcaflex uses.

Model i used is fixed bottom and rna is rigid connection to tower top with same offsets

I will get back to you on point 1 later today

[TheMercer]

Do you have example code snippet that is kept separate from the tool for testing/checking gravity correction you did ?

[TheMercer]

OrcaFlex: 0.23137 Hz, g = 1e-3

Mode number	1
Period (s)	4.322011248177278
Frequency (Hz)	0.2313737615610626
Mass (te.m^2)	1276.3752937046104
Stiffness (kN.m)	2697.530353595687

[TheMercer]

Maybe out of scape, is it worth having the K and M being allowed to be accessed from User so they can do the modal mass and stiffness. Right now in pybmodes I cant check that easily

I get it may never match, like you said near the end..always good to find why they delta and note it

[SMI-Lab-Inha]

That gravity-off run is exactly the test I was hoping for, and it lands right where the estimate said it would. Turning gravity off in OrcaFlex took you from 0.22599 to 0.23137 Hz, a +2.4 percent jump, and the mode-shape estimate I ran for the gravity term was ~2 percent. So term 1 is nailed down and we agree on it.

Even better, your modal mass and stiffness let me split the rest cleanly. Comparing like for like, both gravity-off:

	frequency	modal mass	modal stiffness
OrcaFlex (g=1e-3)	0.23137 Hz	1276 te	2697 kN.m
pyBmodes (no gravity)	0.2437 Hz	~1250 te	~2930 kN.m

The modal masses agree to about 2 percent. So the RNA and the mass side are reconciled, and the whole remaining 5.3 percent frequency gap is in the tower bending stiffness, where pyBmodes sits about 8 to 9 percent higher than your OrcaFlex tower. That is a much tighter diagnosis than "it is a few percent off somewhere".

Now, what makes up that stiffness gap. I checked the obvious one, Timoshenko shear, since pyBmodes is Euler-Bernoulli and your tower is fat (10 m at the base). It only accounts for about 1.3 percent here, so shear is real but it is not the bulk of it. The rest is down to how the two tower models are built, and that is where I need a bit from your side to pin it, because it is now clearly on the OrcaFlex tower rather than the RNA:

• The tower segment count in OrcaFlex, and whether bending stiffness is applied per segment or lumped at nodes. A coarse line discretisation reads softer than a consistent beam FE.
• Where exactly the base is fixed, and whether the RNA is a rigid link from the tower top or has any connection compliance.
• Whether the OrcaFlex tower uses the same wall schedule with the thickness steps, or a smoothed section.

If you can share those, I expect we close to within a percent, same as the outfitting story in #128.

On your K and M access idea, yes, that is worth doing and it is the right instinct. Right now the assembled matrices live inside the solve and there is no clean handle on them, which is exactly why you cannot check the modal mass and stiffness the way you just did in OrcaFlex. I will add per-mode generalised mass and stiffness to the result object (the two numbers you compared above), and expose the assembled global K and M as an opt-in so you can do your own Rayleigh quotient or feed them elsewhere. That turns this kind of cross-check into a one-liner instead of a reverse-engineering exercise, and it is a clean non-breaking addition. Tracking it for the next minor.

You are right that they may never match to the digit, and that is fine. The point is we now know it is gravity (2.4 percent, agreed) plus a tower-stiffness modelling difference (5 percent, and I have it localised), not something hiding in the RNA.

[SMI-Lab-Inha]

The K and M access is in now, on master and shipping in the next release. A solve attaches per-mode generalised mass and stiffness to the result, normalised to unit tip lateral displacement.

res = Tower.from_windio(yaml, lumped_rna_cal=True).run(4)
res.generalized_mass[0]       # kg
res.generalized_stiffness[0]  # N/m

For your clamped tower plus RNA, mode 1 comes out at about 1.15e6 kg and 2.70e6 N/m, and sqrt(K/M)/2pi returns 0.2437 Hz exactly, so the ratio is consistent with the frequency by construction.

One honest correction while I had the real generalised mass in front of me. Lining these up against your OrcaFlex modal output needs the same mode normalisation, and they are not the same. pyBmodes normalises to unit tip displacement, so mass is in kg and stiffness in N/m. Your OrcaFlex report is in te.m^2 and kN.m, which is a rotation-based normalisation, so the raw numbers are not directly comparable. That also means my earlier split of the residual into "the tower stiffness" was not reliable, since which of mass or stiffness carries the gap depends on that normalisation. The one thing that is normalisation-invariant is K/M = omega^2, and that is where the physics lives.

So the solid, agreed part stands. Gravity is about 2.4 percent, confirmed by your g=1e-3 run. For the remaining few percent, rather than me asserting where it sits, you can now read pyBmodes' generalised mass and stiffness directly and normalise both models to the same reference (unit tip displacement is the easy one) to localise it cleanly on your side. If you do that and something still looks off, paste the matched-normalisation numbers here and I will dig in. Thanks for pushing for this, it is a genuinely useful handle to have exposed.