Onderwerp: Rak24u 2025

Hajime schreef :
Routingprogramma's zoeken vaak heel breed naar de snelste route, maar dat is nogal overdreven voor RAK:


Maar waar je wel naar zou kunnen kijken is het berekenen van de snelheid per grid 'vakje' uit de GRIB-file.



Verder zou je de GRIB-file die stappen van 1 uur heeft kunnen interpoleren naar bijv. stappen van 10 minuten.

Jan, wat leuk daar je het weer eens onderhanden neemt! We hebben in het verre verleden veel over wensen gesproken

Wat betreft de kleine wensen:
- ander kleurtje (of stippelllijn!) kan geen kwaad.
- voor de actuele performance kunnen mensen altijd (gratis) Sailing Performance Dashboard nemen

Grote wensen:
- grib2 erbij maar 'gewone' grib behouden! Harmonie voor de dag zelf, GFS voor een weekje vooruit.
- de snelheid tijdens een rak, vooral van belang bij lange rakken. De grib is per uur, dus een rak in kortere stukjes knippen zal dus niets opleveren, tenzij er een uur-overgang in dat rak zit. Dat is natuurlijk 23 keer het geval. Misschien die gevallen welin stukjes knippen,voor en na de uur-overgang?

Niet gehonoreerd:
- golfhoogte zit al enigszins in een ORC-polar. En waterdiepte doet vrijwel niets, alleen bij heel hoge snelheden. Niets aan doen dus.

Andere:
- sluisduur bij Instellingen wellicht dynamisch invullen afhankelijk van welk sluisrak gepland wordt of gevaren is? Nu is er én de compensatie (in de rakken) en deze Sluisduur. Kan verwarring geven.

- een handmatige windtabel afleiden uit de grib. Daarin dan wind per uur (of half uur) en maar 1 kolom voor de plaats. (2 of3 mag ook) Reden: als de wind erg afwijkt van de grib wil je zelf een goede handmatige tabel maken. Niet van scratch, maar op basis van de grib.

Succes Als ik nog wat bedenk meld ik me weer .

Een wens die ik heb is om een ingestelde beperking zoals minimale snelheid of minimale ware wind hoek te laten vervallen als een rak maar een mogelijkheid heeft.
Als bv een start of sluisrak zo ligt dat ie niet aan de voorwaarden voldoet dan is er al snel geen oplossing te vinden. Zou je de voorwaarden alleen voor dit rak opheffen dan wordt er wel een oplossing gevonden.
Een concreet voorbeeld was dit jaar het startrak vanuit Enkhuizen Noord en een minimale ware windhoek van 70 graden. Daar was geen oplossing voor, behalve door handmatig voor. Het rak stsrt - KG een tijdstip van ronding in te voeren. Maar dat is bij een sluisrak lastiger.

Daarvoor kun je toch een boei vastzetten, nog zonder tijd erbij?
Dan dwing je RAK die boei te nemen ongeacht alle instellingen.

Baasklusje schreef :
Dat kan alleen als je de boei op een vaste plek in de lijst zet.
Dat hoeft bij een sluisrak bv niet de beste plek te zijn.

Aha, op die fiets

Jan, wat goed om RAK24 een upgrade te geven en dat terwijl wat mij betreft de huidige versie van RAK24 al super werkt. Ik gebruikt het intensief voor de 24 uurs, maar ook voor de 200 Myls en de 30/75 mijls. En het helpt in alle gevallen.

Met het inventariseren van de kleine en grote wensen, hebben we de neiging om meer functionaliteit toe te voegen. Misschien is het nuttig even te reflecteren op wat er nu in RAK24 zit en misschien door voortschrijdende technologie in andere systemen aan boord niet echt meer nodig is. Ik denk dan zelf aan de panels GPS port, RAK GPS actueel, route en MOB. Ik weet niet wat er verder in de machinekamer zit, maar wat er niet inzit, hoeft ook niet onderhouden te worden.

Een wens van mij zou zijn dat we voor de panels boeien, rakken en stroming een goede import en export routine te hebben met bijv. Excel. We controleren onze data tegen de RWS database, data van wedstrijd organisaties en die info koppel ik meestal in Excel zonder de data zelf aan te raken. Maar daarna moet je dat nog in RAK krijgen en dat vraagt handmatig werk. Zou mooi zijn als we dat dan rechtstreeks kunnen inlezen.

Zelfde geldt een voor de handmatig windtabel. Als we die uit Excel kunnen inlezen, heb je alle mogelijkheden om te spelen met verschillende wind scenario's. Alternatief is dat het handmatige windpaneel meer een gebruikersgevoel als Excel krijgt.

Voor de categorie bug fixes:
Als je het hoofdvenster gemaximaliseerd hebt het bestand opslaat gaat het venster terug naar kleinere afmetingen. Weet niet meer of dat opslaan met Ctrl+S of met een knop was, een van de twee werkte geloof ik wel goed.

Baasklusje schreef :
Zoals je in het plaatje in mijn eerder post kan zien gaan ook kortere rakken (voorbeeld is 4,5NM) langs meerdere punten uit de GRIB-file en kan daar nog best wat verschil in zitten.



Verder is het de vraag wat je moet doen met de tijd tussen twee tijdstappen uit GRIB-file.

Voorbeeld:

Tijd	TWS	TWD
12:00	10	270°
13:00	12	282°

Wordt de berekening er beter van als je tussenstappen gaat interpoleren?

Tijd	TWS	TWD
12:00	10	270°
12:10	10,3	272°
12:20	10,7	274°
12:30	11	276°
12:40	11,3	278°
12:50	11,7	280°
13:00	12	282°

Menno schreef :
Je hebt gelijk, de meerdere harmonievakjes per rak had ik even niet meegenomen.

Mijn ervaring is wel dat het al akelig nauwkeurig is met alleen de huidige oplossing (wind bij start van een rak).
Ik heb de performance in RAK op 96% staan (alle afwijkingen gaan immers naar beneden) en dan voorspelt RAK meestal op de minuut nauwkeurig de volgende aankomst bij de boei.
Die voorspelling staat in RAK en staat op de GPS als ETA obv Closing Speed uit een RMB. Vrijwel altijd urenlang (13mijlsrak) gelijk.
Ik denk dat het een afweging wordt tussen rekensnelheid (die is nu ok) en verbeterde voorspelliing. As ever

Wat betreft het verloop van de wind over een rak vanuit een grib-bestand:
Stel je bent om 12:00 bij Boei KG en gaat naar Boei ELA.
Elke 10 minuten bekijk je waar je bent (=tussenafstand) met de wind die dan geldt op tussenpunt.
Tel tussen-afstanden op tot dat je bij ELA bent. Laatste stukje is wat korter dan 10 minuten ...
Je weet nu de totale benodigde tijd (T) van KG-ELA. Eén waarde T per rak (KG-ELA) per tijdstip (12:00).
Dit wordt opgenomen in interne tabel van alle rakken op alle momenten van 10 minuten.
100 rakken X 25 uren X 6 (10 minuten) X 2 (heen/terug) geeft 30.000 waarden.
Vooraf binnen 1 seconde berekend, denk ik. [Ik heb dit jaren geleden al eens met Menno besproken]

Rekentijd gaat zetten in het achter elkaar knopen van al die rakken en dat kan seconden, minuten of zelfs uren duren.

Het omprogrammeren is een behoorlijk klus.

Baasklusje schreef :
Dus per sluis de wachtijd en het compensatie-percentage in de rakkentabel opnemen ?

"De handmatige windtabel afleiden uit de grib" kan nu al. Zelfs met een zelf gedefinieerde afwijking in tijd, sterkte en richting. Kies in de WindVenster in Grib-tab-blad "Windgebieden behouden, windwaarden copieren" om je eigen windgebieden te behouden, maar te vullen met windwaarden. Eventueel opnieuw interpoleren met tussenwaarden in de Handmatige tabel.

mvdp schreef :
Als de max=1 in de rakken tabel is gezet vervallen de minimale snelheid of minimale ware wind hoek beperkingen.
Dus start- en finish-rak en ook sluisrakken met max=1 worden altijd meegenomen. Anders kom je niet eens weg uit de starthaven etc.

Als je in het IJsselmeer start en je wilt persé naar de Markerwaard, heb je dit probleem wél, want het sluisrak is uitgerust met max=2. Als één van beide "tegen de wind" gaat, wordt dit sluisrak overgeslagen. Of je komt nooit op het Markermeer (zuidenwind) of je komt er nooit meer weg (noordenwind).

Andersom: Als je op het Markermeer start en je hebt max=2 ingesteld, en er zijn geen wind/snelheid restricties van toepassing, bestaat de mogelijkheid dat je eens naar het IJsselmeer gaat en even later weer eens terug gaat en daar nooit meer weg komt, want dan zou je het sluisrak 3 keer moeten afleggen. In dit geval altijd max=1 invoeren.

Menno schreef : Check, wist ik niet. Weet ook nog niet waarom dit zo is. Ga ik nakijken.

Dolphin schreef :
Werkt nu met cntl-C en cntl-V beide kanten op. Selecteer een stuk uit bijvoorbeeld Excel, copy (cntl-C) en plak (cntl-V) in bijvoorbeeld de windtabel waarbij je de TOP_LINKSE cell kiest.
Zorg er wel voor dat PRECIES het aantal rijen en kolommen van de Clipboard-buffer overeenkomen.

Geheel eens met de opmerkingen over het GRIB raster, sinds we de luxe hebben van de fijnmazige Harmonie gribs. Die waren er waarschijnlijk nog niet, toen Rak24u oorspronkelijk bedacht werd.

Het is me deze 24uurs trouwens opgevallen dat Rak24u het gehele sluisrak GVS3M8 -> WV12 zonder stroming berekende. Waarschijnlijk omdat er geen stroming is bij de WV12.

Kortom niet alleen wind maar ook stroming kan baat hebben bij "opgeknipte" rakken in zo'n "10 minuten tabel". Natuurlijk weet Rak24u niet precies waar in het rak de sluis zich bevindt, maar dan nog komt interpoleren waarschijnlijk dichterbij dan alleen het eindpunt (nul, in het sluisrak Den Oever).

Voor het sluisrak door Kornwerd maakt het niet zoveel uit, dat is maar een korte.

Wad rakken blijven natuurlijk een geval apart omdat de koers niet constant is, die volgt een vaargeul. Je kunt moeilijk heel WinGPS overnemen in Rak24u... maar de stroming interpoleren kan al flink helpen denk ik.

Misschien krijgen we dan BK ook nog een keer het wad op

Geheel eens met de opmerkingen over het GRIB raster, sinds we de luxe hebben van de fijnmazige Harmonie gribs. Die waren er waarschijnlijk nog niet, toen Rak24u oorspronkelijk bedacht werd.

Het is me deze 24uurs trouwens opgevallen dat Rak24u het gehele sluisrak GVS3M8 -> WV12 zonder stroming berekende. Waarschijnlijk omdat er geen stroming is bij de WV12.

Kortom niet alleen wind maar ook stroming kan baat hebben bij "opgeknipte" rakken in zo'n "10 minuten tabel". Natuurlijk weet Rak24u niet precies waar in het rak de sluis zich bevindt, maar dan nog komt interpoleren waarschijnlijk dichterbij dan alleen het eindpunt (nul, in het sluisrak Den Oever).

Voor het sluisrak door Kornwerd maakt het niet zoveel uit, dat is maar een korte.

Wad rakken blijven natuurlijk een geval apart omdat de koers niet constant is, die volgt een vaargeul. Je kunt moeilijk heel WinGPS nabouwen in Rak24u... maar de stroming interpoleren kan al flink helpen denk ik.

Misschien krijgen we BK dan ook nog een keer het wad op

Hajime schreef :
Aha, dat wist ik niet. Zat het er al die tijd gewoon in.
Bedankt voor de uitleg!

Maar deze oplossing, rak op 1, heeft weer nadelen.
Een oplossing waarbij voor de sluisrakken, 3 stuks heen en terug, de instellingen altijd genegeerd worden lijkt me fraaier.

Zou overigens ook voor alle rakken kunnen, met een extra kolom per rak, negeer instellingen y of n.

Je wil de rakken rond de finish graag tot einde bewaren maar dan rekent hij er aan het einde ook niet mee. Is daar nog iets slims voor te bedenken?
Bug: als je een rak vastzet rekent hij vervolgens niet meer met de randvoorwaarden als min en max hoek heb ik een paar keer gemerkt, maar of dat altijd fout gaat?
inladen van Grib en stroom automatisch ( als dat niet veel werk is)
Eigenlijk zou je voor de bete route vanaf het einde terug moeten rekenen, maar dat is waarschijnlijk een heel grote verandering.

web schreef : Super interessant...

aluijten schreef : Heeft iemand ervaringen met grib files voor stromingen?
Automatisch is wat moeilijk, want een ieder heeft een andere mening welke grib file het beste is.

aluijten schreef : A: Ik houd me aanbevolen voor een slimmigheidje
B: Beetje onmogelijk. Dit is een NP-probleem. Om niet dagenlang te rekenen moet RAK slim zijn. De grootste troef is de 98% berekening versnelling, en dat moet vanaf het begin ipv het einde om hele zoekbomen af te kappen.

Ja, Jules zeilersforum.nl/index.php/foru...del?start=25#1581320

Baasklusje schreef : Of naast max=1 ook voor sluisrakken instellingen negeren.
Ik probeer extra kolommen in de Traject-tabel te voorkomen.