Currently, SUMMA checks if current_timestep == simEndTime (as specified in the filemanager) and writes a restart file if true.
In cases where the forcing timestep is set such that no simulation is run at exactly simEndTime, no restart file is written. Updating the logic to check whether a timestep is the last timestep (somehow), might avoid scenarios where -r e doesn't work as expected. See example below, obtained from a test case with:
3-hourly forcing timesteps
simStartTime is 1951-04-12 00:00
simEndTime is 1951-04-12 23:00
Note how no simulation is run at exactly 23:00 (only at 21:00 and 00:00) and the restart flag is thus always False.
in summa_alarms: printRestart = F
newtime (m,d,h,min) = 4 11 21 0
endtime (m,d,h,min) = 4 11 23 0
in summa_alarms: printRestart = F
newtime (m,d,h,min) = 4 12 0 0
endtime (m,d,h,min) = 4 11 23 0
https://github.com/CH-Earth/summa/blob/fa9adf808229a45085defdc2bb8ef05836b9b3aa/build/source/driver/summa_alarms.f90#L123-L126
Currently, SUMMA checks if current_timestep == simEndTime (as specified in the filemanager) and writes a restart file if true.
In cases where the forcing timestep is set such that no simulation is run at exactly
simEndTime
, no restart file is written. Updating the logic to check whether a timestep is the last timestep (somehow), might avoid scenarios where-r e
doesn't work as expected. See example below, obtained from a test case with: