Grid interpolation

[RRiva]

Hi all,

Thank you for the great work with WindIO 🙂 One problem that I see is how to interpret the various grids. For example, HAWC2 will interpolate a grid using the Akima spline, while OpenFAST might do something else and QBlade yet another thing, which will lead to 3 different blades. Obviously, little can go wrong if there are many grid points, but differences will arise when this is not the case. I suggest adding a new keyword interpolation_method to each grid, values pair. The acceptable values for interpolation_method could be taken from an enumeration, which contains:

• linear
• akima (default?)
• pchip
• cubic_spline
• Maybe more from scipy.interpolate

Finally, the equations for each interpolation method should be part of the WindIO specification.

What do you think about this?

Best regards,
Riccardo

[fzahle]

Hi Riccardo,
We had an email exchange on this topic and I'll paste in what I wrote to Pietro and some others:

I’ve also had a long chat with @kenloen, where one topic that came up was allowing to specify array quantities using splines rather than the discrete format windIO currently only supports. And this actually leads me to proposing to backtrack on the removal of grid/values pairs for the planform quantities. If we keep it for the internal structure it really would be more consistent to keep all across the board. And the added benefit would be to extend a grid/values definition with a spline with breaks and coefficients. This was actually done for the DTU 10MW RWT, but never made it further, see appendix 1 in the report: https://gitlab.windenergy.dtu.dk/rwts/dtu-10mw-rwt/-/raw/master/docs/DTU_Wind_Energy_Report-I-0092.pdf?ref_type=heads. Grid/values can continue to be default, but an additional sub-dict could be optional:

                twist:
                    grid: [0., 1.0]
                    values: [20., ..., 3.0]
                    spline:
                        type: cubic
                        breaks: []
                        coeffs: []

I think we all use splines internally in our codes, but lose all the fidelity of these as soon as we discretize the curves in windIO leading us to define curves with high grid resolution. It would be relatively easy to implement support functions in windIO for translating two ways, helping users transition to splines.

As a starting point users could simply use

                twist:
                    grid: [0., 1.0]
                    values: [20., ..., 3.0]
                    spline:
                        type: cubic

and if not defined, people can use windIO (scipy) to spline the data.

@ptrbortolotti I promise that Riccardo's suggestion is not coordinated with what I wrote :-)

[RRiva]

Thanks Frederik! I like this solution 🙂 But, if you decide to implement it, then there should also be an automatic check to make sure that the grid, values pair matches the spline.

[fzahle]

We currently have quite a few tasks on our plate to mature windIO 2.0, so I think we'll focus on those changes first. But if we implement it as above, it'll be an addition and backward compatible, and we can add it in a next round of development..