Onderwerp: Vraagje voor zeilende wiskundigen.....

SailingPD schreef :
Waarom denk je dat dit beter is dan een lineaire interpolatie tussen speednarrow en speedwide?

Dat denk ik niet per sé. Ik vraag het eigenlijk
Beide berekeningen (lineair en deze) staan nu in het programma.
Ik kan simpel wisseln.
Het verschil tussen beide is bij 6 a 7 kts meestal minder dan 0,1 kts Target Speed.
De polar is natuurlijk wel een kromme, niet een reeks rechte stukjes met knikjes....

Ingewikkeld. Bij elke interpolatie (ook 1D) moet je eigelijk weten hoe de functie verloopt om iets te kunnen zeggen hoe een interpolatie eruit zou moeten zien.

Hier een polar in 3D (niet in pool-coordinaten maar cartetisch weergegeven).



Ik zou eerste eens (“gewoon” in Excel) proberen:
-hoe je bij een gegeven TWS tussen 2 TWA waarden zou kunnen interpoleren
-hoe je bij een gegeven TWA tussen 2 TWS waarden zou kunnen interpoleren

Ik ben bang dat dat niet overal in een VPP matrix op dezelfde manier kan.

Die cosinus lijkt mij redelijk willekeurig? Hoe ziet die eruit als je die Excel oefening doet, dus in de grafiekjes die je eerder liet zien?

In NumPy/SciPy zitten ook al interpolatie functies, bijv:

kx en ky zijn de degrees van de bivariate spline. kx=ky=1 is lineair, default voor kx en ky is 3.

Nachtvlinder schreef :
Be my guest

Ik heb niet voor niets voor bilineair gekozen

Wat Menno voorstelt lijkt mij het proberen waard. Weet niet of die methode ook door de wel bekende punten gaat of daar zo dicht mogelijk langs loopt? Orde dus 1 of hoger; betekent “2” dan dat je aan beide kanten van de te vinden waarde 2 bekende punten beschikbaar moet hebben? Weet niet hoe zich dat dan gedraagt aan de randen van de tabel? Zitten vast wat slimmigheidjes in.

stackoverflow.com/questions/46...terpolation-in-scipy

Ik vermijd NumPy en SciPy.
En wel omdat ik een kleine distributie (library) wil hebben in een gecompileerde versie.
Die hoeveelheid is nu 23.8 Mb, waarvan zo'n 15 Mb dingen in libraries die helemaal niet gebruikt worden....

Zelf bedenken dus

Cubic of de meer controleerbare Hermite interpolaties gaan door de bekende punten (2 aan elke kant) en passen denk ik goed bij het typisch verloop van een polar curve:
paulbourke.net/miscellaneous/interpolation/





Aan het eind van de tabel wordt het wel tricky en zal op een alternatief overgegaan moeten worden. Aan de UA kant wel jammer want juist daar geeft lineair de grootste fouten (en is de targetspeed gevoelig).

SailingPD schreef :
OK, ik ben bevoorrecht dat ik me niet druk maak om 100% performance, maar je miste wellicht de belangrijkste opmerking:

Deze jongens en met name Zezo hebben er verstand van.

JotM schreef :
Als lezen lastig is snap ik ook waarom je dit zo boven de pet gaat

In mijn toepassing zijn er geen tussenliggende punten..

Een NURB is per definitie niet geschikt om op een dataset te fitten.

Nou, ik heb wat handmatige bicubic interpolaties gedaan op 3 punten uit de First 31.7 polar. Het verschil met eenvoudige bilineaire interpolatie is wat mij betreft verwaarloosbaar.

TWA	TWS	BiL	BiQ
155	22.5	9.0	8.9
38	7	4.5	4.6
140	27	10.5	10.7

Verder nadeel is zoals genoemd, dat je in zowel TWA als TWS dimensie aan beide zijden rondom het te schatten punt 2 datapunten nodig hebt. In de buurt van UA en de randen van het windbereik werkt deze methode dus niet - en binnen in de tabel is het verloop zo vlak dat lineair prima werkt

Denk dat een goede interpolatie (evt stukje extrapolatie tussen UA en TWA=0?) nabij UA en UD belangrijker is (dat de afgeleidden van de VMG daar netjes 0 zijn)...

Voorbeeld:

SailingPD schreef :
Dat mag natuurlijk, maar waarom? Wat maakt het uit als je library 80MB is i.p.v. 23.8 MB?

he Maarten, dank je.
Het verschil tussen lineair en iets kroms komt dus weer neer op 1 a 2 % van de target speed (en dus van performance); daarmee valt het een beetje in de ruis.
Dezelfde soort verschillen had ik ook al gezien.
De vraag wat nu beter is blijft overeind natuurlijk.
Als lineair over korte stukjes van de polar goed genoeg is, is iets kroms dan toch beter?

En zoals je zegt: het echte probleem is aan de rand van de bekende polar, vooral bij TWA < UA.
De prestatie van de boot loopt daar (meestal) snel terug, zeker als je langere tijd te hoog stuurt. De regel van Gladstone is niet voor niets 'speed first, then pointing'.
Niets is dodelijker dan met weinig snelheid heel hoog sturen; de drift neemt enorm toe.

Interpoleren naar 0 kts bij TWA 0 is m.i. dan ook grote onzin. Je gaat dan geen 0 kts; je gaat achteruit.

Inderdaad wat snelheden in de polar opnemen bij TWA net onder de UA helpt; maak ze maar gelijk aan die bij de UA, dat vaar je nooit en de performance zal drastisch afnemen bi TWA onder de UA. Dat zal ze leren Het heeft geen zin jezelf voor de gek te houden met 100% performance als je te hoog vaart of te ruim. De VMG zal je ongelijk dan aantonen.
Uitzondering kan zijn heel hoog varen met de stroom achterop. Dan kan je hoog en hard. Ik denk dat performance daar niet meer de juiste info geeft; in die situatie moet je de VMG zo hoog mogelijk maken, zelfs als daar pinchen voor nodig is.

grappig, ik lees nog mee (het meeste snap ik ) en de conclusie is tot nu toe dat mijn jan-boeren-fluitjes aanpak van lineair extrapoleren net zo goed als met ingewikkelde krommes? Beetje flauw van me Ik vind het wel een leuk en leerzaam draadje geworden!

Inderdaad, waarom makkelijk als t moeilijk kan?

Niet zo zeuren Chris! Dit gaat echt wel convergeren, SPD filtert de ruis er wel uit. Kan geen kwaad om over na te denken toch!?

SailingPD schreef :
Ik zal grafisch nog laten zien of deze bicubic interpolatie beter aansluit op het verwachtte verloop tussen de tabel-punten (in 1 dimensie dan). Als dat zo is, dan is tie beter (hoe weinig ook)

SailingPD schreef :
Dat lijkt mij praktisch en voorkomt “222” als je een kortstondig paar graden van koers raakt door een golf ofzo. De reden dat veel polars die wel tot TWA=0 doorlopen zo’n hartvorm hebben is denk ik dat deze ook in routing software gebruikt worden. Je bouwt dan een natuurlijke constraint in waardoor er niet boven UA gerouteerd wordt zonder numeriek op harde constraints terug te moeten vallen.

Maar toch nog even - stukje polar van Erik:


Als ik grafisch kijk naar deze curves tussen zeg UA-10 gr en UA+10 gr, dan zie ik een zo goed als symmetrische ellips. Horizontale raaklijn bij UA, geen knikpunt bij volgende “standaard” ORC TWA punt.

Zou dat niet te parametriseren zijn?
-lastigste en belangrijk deel net onder UA wordt dan “natuurlijker dus beter dan lineair”
-tot UA-10 ziet het er kwalitatief uit als de Erik en F31.7 polar (die berekend niet verzonnen zijn)

SailingPD schreef :
Ik zou het omdraaien: je stopt het polair diagram in SailingPD om een target te hebben voor je performance, niet om daar routing mee te doen. Bij TWA=0 heb je een target: de BeatVMG.
Als je een BeatVMG van 5 knts hebt, en je gaat in de praktijk 2 knopen achteruit, heb je een performance van -40%

De target bij TWA < UA moet voor SailingPD dus hoger staan dan je in de praktijk kan halen, in tegenstelling tot bij routing programma's zoals RAK.

Voor het hele stuk tussen 0 < TWA < UA kan je die hoge target berekenen met de BeatVMG en een cosinus.

Dat is ‘em Menno! De “performance target polar” volgt tussen TWA=0 en UA de denkbeeldige horizontale raaklijn die door UA loopt!

Hier voor 4 en 6 kn TWS:


En dan zijn er hiermee nu ook >2 datapunten beschikbaar om dat bovenste stuk tussen UA en het eerste standaard ORC TWA punt netjes te interpoleren

Nachtvlinder schreef :
Zei ik dat niet ook om 19:46 ongeveer:

Iets drastischer dan die willekeurige horizontaal
Dus, wie geen nullen in zijn polar wil (als waarschuwing met de 222) zet gewoon de Target Speed bij UA ook bij alle kleinere TWA's. Klaar. Performance lazert in elkaar als je te hoog stuurt. Idem bij DA

Die horizontale lijn IS de BeatVMG! Je VMG target bij opkruizen is waar die lijn de vertikale as snijdt. Bijbehorende polarspeed is BeatVMG / cos(TWA). Niets willekeurig

SailingPD schreef :
Mooie hersengymnastiek heren! Ik lees meer grote ogen mee: “hoe doen ze dat”

Maar die 222 of 111 is wel een super duidelijk signaal op, ik noem iets geks, een I70s in de garage, waarbij mijn stuurman niets hoeft te begrijpen hoe SPD werkt. Alleen te onthouden dat als hij dat ziet hij te hoog of te laag stuurt.

Ok, het plan is me duidelijk.
Aan SailingPD hoeft niets gewijzigd te worden.

In de polar zet je de nullen als je in uncharted territory van de polar komt voor als de de 222 als waarschuwing wil krijgen. Als SailingPD dan een nul tegenkomt gaat hij niet interpoleren maar geeft de 222 af.

Voor mensen die dat niet willen:
- maak extra rijen in de polar voor TWA's 10, 20, 30, 35 (of zo)
- zet in de cellen waarvoor geen polar-waarde beschikbaar is de snelheid die je moet varen om de VMG van de TWS van die kolom bij de UA van die rij te halen.
Dan krijg je zo gauw je onder de UA komt meteen te zien dat de oerformance daalt, want je kan die VMG nooit halen (want de UA is de beste oplossing voor hoogste VMG).

Dank Menno en Maarten voor het meedenken.
Ik zal straks een voorbeeld posten van beide soorten polars, en een hulp=XLSje maken om de snelheden te berekenen die moeten worden ingevuld.

Blijft alleen de originele vraag van deze draad nog over: wat is nou beter? Lineair of een bochie.

Een (welke!) "kromme" interpolatie is natuurlijk beter: het daarwerkelijke verloop is in ieder geval niet piecewise lineair

Ik heb al laten zien dat het verschil met een robuuste lineaire interpolatie klein is. Hieronder de 14 kn isotach uit de F31.7 polar met daaronder een stukje uitvergroot. Hoewel de discontinuiteit in de afgeleidden van de lineaire interpolatie fysisch niet mogelijk zijn en deze daarmee "onjuist" zijn, is de fout maar heel klein.

Ik zou het dus maar bilineair houden. Overige argumenten:
-dataset is non-equally spaced: uitwerking zonder gebruik libraries wordt complex
-nabij de randen van de matrix zit je sowiezo vast aan een andere methode

SailingPD schreef :
Je polar file is dan een vorm van config file. Even editen om het gedrag van SailingPD aan te passen. Hoe gaat SailingPD software om met polar’s waar geen optimale UA of DA in vermeld wordt ? Moet de gebruiker die er zelf maar in knutselen ?

Maar we geloven er nog steeds in hoor !

Da's nie zoveel werk hoor, polardata die wel beschikbaar is in Excel dumpen en VMG=BSP*COS(TWA) laten berekenen. Hier ook gedaan. Volgens Finot 37.5 en 167 gr. Klopt heel aardig (de apart vermeldde UA en DA punten heb ik niet ingevoegd in deze grafiek)

De dunne lijntjes links in de grafiek zijn de BeatVMG en bijbehoredne BSP als je die VMG bij TWA<UA zou willen halen doorgetrokken. Dat wat SPD ten onrechte een willekeurige horizontale lijn noemde