-
Notifications
You must be signed in to change notification settings - Fork 0
Reading of the forcing
In order to make the code works properly, the time between two consecutive data in the forcing should be divisible by the timestep duration and the timestep be "aligned" with the time in the forcing. If this is not the case, unexpected behavior can occurs. Unless specified otherwise, all the times are in the code as second since epoch (01/01/1970), even is only presented in HH:MM in this wiki page. Every value above 10²⁰ or below -10²⁰ in the netcdf forcing will be put at 0.
The variable stored in the forcing that are time dependent (current, wind, temperature...) exist in OSERIT in two version each, at two consecutive timesteps. To do so, two variables storing the time of the current timestep (time_since_epoch) and the time of the previous timestep (time_since_epoch_prev) are updated at the start of each timestep.
When a variable must be read, like for instance the current at a given location, OSERIT will do several step (everything is more or less the opposite in backward simulations):
The higher layer defined in the cfg which contains in its boundaries the location request will be selected
There, the program will determine if the value stored in the memory are the correct one or if new one must be read.
Using an algorithm described further down (cf "how to get the correct time"), two times are determined: the time of the lower bound for which time_since_epoch is strictly above and the upper bound for which time_since_epoch_prev is strictly under. The two bound are following each other.
With a forcing containing the times 08:00, 09:00, 10:00, 11:00, 12:00
time_since_epoch_prev |
time_since_epoch |
lower bound | upper bound |
|---|---|---|---|
| 09:00 | 09:10 | 09:00 | 10:00 |
| 09:30 | 09:40 | 09:00 | 10:00 |
| 09:50 | 10:00 | 09:00 | 10:00 |
| 10:00 | 10:10 | 10:00 | 11:00 |
At each variable time depend, there is a time corresponding at the time in the forcing which is attributed. There is also two variable in memory for each variable in the forcing, the "next" variable and the "previous" variable, with the "next" and "previous" time.
If the time of the lower bound is:
- equals to the previous time, nothing needs to be done, the good value are already in memory
- equals to the next time, this means that the previous variable must be updated to the value of the next variable, the previous time also become the next time. This happens when the model reach the next hour for instance
- no equals to next or previous time. There the variable must be reload from inside the forcing after looking if a new file should be read. The previous time is updated such as the array of time value.
There are only two possibilities there, either the upper bound is
- equals to the next time and nothing needs to be done
- or it is not, and in this case the variable should be reloaded from the forcing file after looking if a new file should be loaded. The next time is updated. It is at this time that the depth is updated if it is a 3D array with the same procedure as described here.
The value for the variable at the lower bound and the upper bound are read using nearest neighbor or a trilinear interpolation at the location of interest.
To get the value, a linear interpolation is done with the previous and next time, (time_since_epoch) or (time_since_epoch_prev) depending on the variable that should be read.
To get the correct time (the time that is bounding above or below the time of interest), 4 information are required :
- the target time
- An array with all the times in the forcing file
- The duration of the forcing time
- If it is the upper or lower bound that should be read
The array of timestep in the forcings are very usefull here, two are needed when the two times are in different files. The "old" one is updated when a new value is read for the "old array" or when the value of
time_since_epoch_previs in the time array of the next array (this will happens when a new variable needs to be read after being copied when changing of file).
There are three possibilities:
- The target time is under the lowest value of the array, then the value is in one of the previous files
- The target time is above or equals to the duration of the file, then the value is in the next file
- The target time is above a value in the array and strictly under the next one/duration of the file => the time of interest is the value just under or equals to the target time
There are also three possibilities:
- The target value is above the highest value of the array, then the value is in one of the next files
- The target value is below the lowest value of the array, then it is not possible to know if it should be the first value of the array or one from another file, and therefore assumed to be the first value from the current file. This could cause some inaccuracy at the start of backward simulations, so if another file is read, the last value from the previous array will be added.
- The target value is strictly above a value of the array but below the next value of the array => the time of interest is the value just above or equals to the target time
If the target time is not in the file already open, a new one must be read. 4 case are possible:
- low bound, previous in time
- low bound, next in time
- high bound, previous in time (should not be possible?)
- high bound high in time
Simply load from the target time
To avoid getting stuck, for instance at 23:30 for a forcing starting at 00:00, the delta between the last and the time before last of the array is added -1 second, for the case we are at 23:00