12 | | Where dt is the time step of the forcing file. |
| 12 | Where dt is the time step of the forcing file. |
| 13 | |
| 14 | '''AD (26/5/16)''': Note that, in the above case, the time at which we read the forcing is t+dt. Let's introduce an index itau of the forcing records: itau=1 is the first record in the nc file for all variables, etc. |
| 15 | Imagine we are currently reading the record itau_n, coming juste after the record itau_nm1. These are the notation of dim2driver/read2dim, and we have itau_n=itau_nm1+1. The "time_stamps" corresponding to these two records are separated by dt (the dt between two records, and not dt_sechiba: dt=split*dt_sechiba). To make the link with the above notations of time, the time stamp of the record itau_n is t+dt, and the one of of itau_nm1 is t. |
| 16 | |
| 17 | Now we need to remember where we are in the code, and what we need the forcing for. When we read itau_n, with values corresponding to t+dt, sechiba hasn't yet run between t and t+dt. It has run (or been initialized) up to t, with forcing controlled by the forcing records itau_nm1 and before. '''So when we read the record itau_n corresponding to the time stamp t+dt, we know the state of sechiba at t, the forcing values at t (from itau_nm1), and we want to correctly define the forcing variables over each dt_sechiba between t and t+dt (dt=split*dt_sechiba).''' |
| 18 | |
| 19 | For me, these are general principles which need to be true whichever the forcing if we decide to read together all the variables that have the same time stamp. The fact that fluxes are averages over a period of length dt after or before the time stamp can be dealt with in the above general framework, at the initialisation stage (but the latter is an opinion). |