Wind on VR
Post by iconPost by Tigrou26 | 2018-11-02 | 13:38:04

Do you know hox the VR winds are obtained from GFS (NOAA files)?
Does VR use 12h file, 6h file, 3h file ? How do they make the different computation ? Time interpolation and space interpolation between le full degree points ?

commenticon 11 Comments
Post by iconPost by zezo | 2018-11-02 | 15:13:34
3 hour GFS, 1 degree resolution, temporal and spatial interpolation.

Data comes in the original U/V form, temporal interpolation is linear in that space.
Post by iconPost by philou83 | 2019-05-11 | 09:50:56
Hi Cvetan,

This means that VR uses full UV for spatial interpol ?

Thanks
Post by iconPost by zezo | 2019-05-11 | 17:45:29
Yes, a quite complex formula, taking in account both averaged U/V AND averaged effective wind speeds.
Post by iconPost by Tigrou26 | 2018-12-27 | 16:25:26
hello Cvetan

I need some more information on how VR uses the GFS wind

1. the GFS time for GFS is UTC time : does VR use exactly these wind values u,v dated UTC 0,6,12,18 but with the time of the game 1,7,13,19

2. if we admit the item 1 above, I would to know how they go from Oh UTC prediction to 6h UTC prediction when this last one begin to be known at 3h30 UTC
Do they wait till 5h UTC when all the value will be known and transfered by NOAA to commute from the last prediction to the new prediction ?
When they decide to make this commutation do they make a step or linear application of the differencies , at which time and durind what duration ?

Thank you for your answer


Post by iconPost by zezo | 2018-12-27 | 17:03:15
0) The data sent to the client is not exact UV values. It's subjected to a formula involving square root and constant factor. Not sure if the server uses the same data or the original numbers.

1) Game interface runs in user local time now, so it's 01 for you, 02 for me and 00 for someone in UK, so let's stick with UTC.

2) When applying the new GFS there is interpolation between the old one and the new one for the same moment in time.

Like, the weather for 00 UTC is interpolation between 12z+12 and 18z+6. Not just average, but weighted according the exact moment in time. The resulting number is then interpolated again with the 12z+9 data to get the exact conditions.

The above statement is not 100% verified because I never bothered to reimplement it with 100% accuracy.

It won't be very hard to pinpoint the exact implementation details, but you have to do it for the client and server separately.

One possible approach to check the server calculations is to get a test boat parked with TWA 0 at exact integer degree position, preferably somewhere with unstable weather and log the server-side wind data with the extension.
Post by iconPost by YourMomSA | 2019-05-11 | 14:45:16
Presumably at some point in there it also applies the 2-kt minimum.

I was hit pretty hard at the very end of my first Yokohama run by the difference between the server data and the onscreen data. A 2-kt dead spot came through the finishing area, and the forecast changed just as I was approaching, so I was encountering 40-degree differences between the angle shown in the interface and in the dashboard. I ran aground trying to sail TWA. Total mess. Should have straight-lined it with C0 and ignored the sail warnings. Won't matter though, if I can do a faster run later.

That experience and this topic have me wondering a few things:
-When server and client differ, which matters?
-Which side drives the autosails decisions?
-Which side drives drives the sail choice recommendation when manually choosing sails?
-Which side drives the onscreen "wrong sail" notificaiton?
-Which side drives the "wrong sail" email notification from the radio?

My guess is... server, server, client, client, server... Meaning you can't trust your eyes in those situations and need to either rely on the autosails or trust the dashboard over the client's sail messages when choosing sails manually.

A related question... Anyone know what tolerance is built into the autosails decisions? I assume it doesn't change sails immediately when a new sail is 0.001 kt faster than the existing sail, or there would be excessive problems with sails flipping back and forth. But if I'm right, then it could also mean there would be times when you might sail with a slightly incorrect sail for a long period of time, failing to exceed the autosails threshold for a change, if you don't change manually. Which gets tricky if you can't trust the client data. Not a big enough topic to matter often, but interesting to understand.

Anyway... I was actually responding because of Cvetan's proposed experiment. I have a thought on that, which is that perhaps enough people are interested in the topic for the experiment to be worthwhile, but perhaps no single person is wanting to do the whole thing. I'd like to suggest that if three volunteers can be found, it could be done as a team effort:

-Volunteer 1: Weather / GFS guru: Identify the best coordinates for the test, and advise the Data Gatherer when to capture the data.

-Volunteer 2: Data Gatherer: This can be anyone with the Dashboard installed who doesn't mind taking a Yokohama Ultime to coordinates proposed by the Weather Guru within a few days' sail of Honolulu. I'm guessing somewhere near Fiji. When you get very close to the precise coordinates, change to the wrong sail, so that you can sail exceptionally slowly. Go to exactly TWA 0.0 when at exactly the desired coordinates. Then capture the required data when the Weather Guru recommends. The key is to be at exactly the right coordinates for a couple hours or more. Preferably for days. Main skills required are patience and the ability to get your boat to a precise coordinate and keep it there.

-Volunteer 3: Data Analyst: This is the person who knows how to use the gathered data, and the GFS data, to obtain the interpolation details. I think this person also needs to be able to advise the Weather Guru on what kind of weather is needed... Simply a big wind shift? Or do we need a case where the new forecast is going to significantly vary from the prior forecast for the same time (ie, volatility in the wind or forecast)? And... is it ok if the windspeed is 2.0, or does it need to be in a place where the wind is larger while still being volatile? Because it's easy to find wildly variable forecasts around the Solomons, but it's also a lot of 2.0.


Just thinking aloud. No worries if we aren't able to assemble a team for this analysis, particularly given that I'm not volunteering for any of the roles myself.








Post by iconPost by zezo | 2019-05-11 | 18:03:17
Everything but the manual sail recommendation/warning is server-side indeed.

Not sure about the current sail change logic, but I haven't seen it do something very stupid.


About the proposed experiment you need a spot with a volatile forecast. The data record can be collected with the dashboard, a manual record can be collected with the on-screen data to see how it differs with the server.

Analysis should not be very hard. In a spot with integer co-ordinates only a linear interpolation between the wind U and V components is involved.

First question is how the three files (past data point from old GFS and future data points from the old and new GFS) are interpolated.

Second question is when the data is sampled in each case. Exact 5 minutes/previous round 10 minutes/next 10 minutes and so on.
Post by iconPost by toxcct | 2019-05-14 | 12:38:04
Also, as none replied about that yet, here what we can find in the polars (all boats share the same values so far) :

	"autoSailChangeTolerance": 1.003,
"badSailTolerance": 1.01,

Post by iconPost by MidnightFoiler | 2019-05-14 | 11:00:19
YourMom, my experience towards the end of the Mini en Mai confirms with what you think about server/client side for sail changing. Halfway up the last leg where we were switching from Staysail to Jib to LJ, I got warnings to switch to Jib when dash was quite happy on Staysail as it was still over the limit there but not in client.

Later I had switched to autosail and decided I might as well tack a little early to do a tack change to LJ (to combine the penalties). Client was saying I was on LJ already but dash said I was on Jib and this continued for 2 more 5 min updates before I decided to tack and manual change to LJ - it was tricky because I wanted to switch auto off to Jib and then tack once I was sure the server was in LJ range but I dare not risk an extra couple of changes if it had already switched on the server since the last update ... all things you think about when you are seconds in the lead!

I still don't know if it auto changed before the tack or not as I tacked 2 mins after the last update - at least this way I didn't do any extra changes. I wonder whether it only changes sail on 5 min updates or changes of course or if it can happen at any minute?
Post by iconPost by DonJuan21 | 2019-05-16 | 07:25:35
For that matter, are we sure the server side takes course changes immediately or does it wait for the next 5-min communication update? The little green arrow ding makes you Think it has been accepted, but is that true?
Post by iconPost by zezo | 2019-05-16 | 11:03:41
Submitted time, give or take 1 minute. But there are some quirks:

- Server works with client-side time stamps. So if your PC clock is one hour ahead and you issue a command, it will be interpreted as programmed turn in one hour and executed 1 hour later.

- When issuing a command around the update time the server may or may not execute it immediately, so there is +/- 1 minute uncertainty.
border
Topics list
Posts
border
5
border
border
3
border
border
1
border
border
2
border
border
4
border
border
6
border
border
Copyright 2009 by ZEZO.ORG. All Rights Reserved.