wxstall / GridsSimp

0 stars 0 forks source link

Consistency check extend time range #10

Closed wxmanted closed 6 years ago

wxmanted commented 6 years ago

Consistency/integrity check and derivation of elements likely needs to extend beyond a user's predefined time range.

Noticing that with 2 people doing grids at certain times the hourly temperatures from diurnal are often using the previous forecast's max/min temps. So say the previous forecaster forecasts a low of 65. The long term forecaster comes in several hours later and runs diurnal and finishes their grids. The short term forecaster an hour after that raises the lows to 68 and runs all the "finalizing" stuff. Now there's a likelihood that hourly temperatures at 13z are now below the new minT forecast. That's a no-no.

Note this problem occurs a lot with the way grids are split up - having nothing to do with what tool we use. The only solution is to run diurnal and finalize again to fix everything. I don't think I would want to run diurnal again, because that opens up a huge can of worms with winter temps and asking other forecasters what to do etc. Potentially winter precip would have to be re-done altogether.

But I think the way to solve this is to just extend the automatic calculation of integrity checks and derived elements to the final hour of the maxT and minT time range when it spills past a user defined time range. So if a user picks it to end at 12z, the check and finalize should extend itself to 14z. Likewise 0z should be extended to 1z. Now the disadvantage to this is that the temp grids may not be very realistic. There could be jump of several degrees or a plateau for a few hours at a certain temp. The winter related PoT grids would have to be derived based on the "fixed" temperature but at least it's at a time when the forecaster is looking at them.

The second way to fix the problem we'd have to train forecasters that nights don't end at 12z, but 14z and days don't end at 0z but 1z. This opens up the can of worms of PoP bleed over. We would hard code the today, tomorrow, day 4, to stop at 1z and 14z for all temperature related stuff, but not touch PoP, sky, wind grids beyond 0z and 12z. Note this could create an issue in the winter time - where the forecaster may need to be concerned with precip type in those overlap periods, but not have "control" of the PoPs.

Another way to fix the problem is that when GridsSimp asks to publish grids and does a final integrity check. It fixes any issues. Note that this might cause temps to change and would require pot grids to change during winter weather, which would cause the forecaster to have to re-do something all over.

I think solution 1 is the best and easiest way to fix it. Maybe eventually solution 2 could be employed in the future.

wxstall commented 6 years ago

Fixed for 0.1.3

Max/Min T time ranges now used for integrity checks and derived field calculations