Updated definition of structural damping

[RRiva]

Updated definition of structural damping

We replace the definition of structural damping, which was mu from BeamDyn, with the more general damping ratio.

Related issue

#192

Impacted areas of the software

Additional supporting information

Test results, if applicable

[RRiva]

Hi @ptrbortolotti, what do you think? If you like it, I can update the turbine models.

[ptrbortolotti]

this makes sense to me... thank you very much for doing it

[ptrbortolotti]

@RRiva thank you for this PR. should I work to fix the tests?

[RRiva]

Hi @ptrbortolotti, sorry for the delay. I'll update the turbine models next week.

[fzahle]

we'd also need to update windIO2windIO: https://github.com/IEAWindSystems/windIO/blob/main/windIO/converters/windIO2windIO.py#L473 and since this is a backward incompatible change it'll have a wide impact across our RWTs.

[RRiva]

I've now added the damping ratios, but I still have to name the modes.

[ptrbortolotti]

Table 3 in https://iopscience.iop.org/article/10.1088/1742-6596/2767/5/052042/pdf has the modes for the IEA22
For the IEA15, this is a start https://iopscience.iop.org/article/10.1088/1742-6596/2767/2/022018/pdf, but unfortunately I don't find the list of the higher modes

[ptrbortolotti]

@RRiva please let me know if you need any help here

[RRiva]

Sorry Pietro, it's a busy period, but I promise to finish this PR.

[ptrbortolotti]

I believe we should add a description field in the actual yaml that describes what those values represent. There is a million different ways to compute modal parameters, and values without those details become somewhat useless. I'd be inclined to avoid being overprescricptive in the schema and let users provide what they have. What do you think?

[RRiva]

I see your point, but there are already 3 description fields. The first reads "Structural damping ratios of the undeflected beam at standstill, subject to appropriate boundary conditions.". Let's break it down:

• "Structural". Obvious.
• "damping ratios". Well-defined quantity, also specified in the other description field: "computed as - Re(lambda) / abs(lambda), where lambda is an eigenvalue."
• "undeflected beam". This implies that I consider pre-bend but not blade deformation. At this point a user might ask: does the structural damping depend on the blade deformation? Maybe, but no code allows that, because it would require a very concise description of the deformation. The same argument applies to the stiffness properties.
• "at standstill". I assume that the centrifugal stiffening does not affect the structural damping.
• "subject to appropriate boundary conditions". This is the most controversial point, and I wrote it like this to keep it general and not corner myself with an overly restrictive definition. In my opinion, the boundary condition should reflect how that component will be assembled in the multi-body model. This means:
  • Blade: a fixed-free configuration approximates quite well the connection with the hub. I didn't want to start a discussion with the researchers who used free-free.
  • Shaft: a free-free configuration should be correct. I'm not sure if external masses and inertias should be considered, but I expect that their impact on the damping is negligible.
  • Tower: a fixed-free configuration approximates quite well the connection with the ground. Since the RNA weight affects the natural frequencies and mode shapes, that should be included too. However, I expect it to have a negligible impact on the structural damping.

I also didn't write how the structural damping should be computed, because there are entire books dedicated to system identification.

Since a user is free to write additional comments in his model, I agree with you to not be overly descriptive 🙂

[ptrbortolotti]

good points, I agree with you. if you can resolve the conflicts, then I'm good to merge!

[RRiva]

Done 🙂