predict.py writes wind data into the gfs folder; filenames it writes contain the time of the wind data, its location, but NOT the model, with the idea being that predict.py overwrites old data so it's all fresh for the C binary to use
However, due to different lat/lon windows this kind of thing can happen:
python "writing gfs/gfs_1356523200_52.0_0.0_3.0_3.0.dat"
C predictor "reading gfs//gfs_1356523200_52.0_0.0_3.0_10.0.dat"
In this case, that file (gfs_1356523200_52.0_0.0_3.0_10.0.dat) was created for another prediction, and the C predictor picked it instead (maybe because alphabetical, or random ordering of files). That file infact contained data from the 20th of December (rather than the 23rd)
There's a second bug fixed: in addition to getting wind data for times between 'mintime' and 'maxtime' (set to launch - 1 hour launch + 5 hours respectively by PHP) we need the adjacent times on the left and right of those, so that the predictor may interpolate.
predict.py writes wind data into the gfs folder; filenames it writes contain the time of the wind data, its location, but NOT the model, with the idea being that predict.py overwrites old data so it's all fresh for the C binary to use
However, due to different lat/lon windows this kind of thing can happen: python "writing gfs/gfs_1356523200_52.0_0.0_3.0_3.0.dat" C predictor "reading gfs//gfs_1356523200_52.0_0.0_3.0_10.0.dat"
In this case, that file (gfs_1356523200_52.0_0.0_3.0_10.0.dat) was created for another prediction, and the C predictor picked it instead (maybe because alphabetical, or random ordering of files). That file infact contained data from the 20th of December (rather than the 23rd)
There's a second bug fixed: in addition to getting wind data for times between 'mintime' and 'maxtime' (set to launch - 1 hour launch + 5 hours respectively by PHP) we need the adjacent times on the left and right of those, so that the predictor may interpolate.