issue with cbmi time controller

[JannisHoch]

When running a coupled PCR-CMF model, CMF is updated several times before the specified simulation period.
Since both models and the starttime (-s in command line) are all set to the same date, this behaviour suggests a bug in the code.

Here the files for documentation (had to rename some to txt as nam/ini is not supported).
input_flood.txt
setup_PCR2CMF_30min_Bangla_glofrim.txt
glofrim_PCR2CMF.log

[DirkEilander]

We found that the shift in timing has to do with the leap year setting in CMF (LLEAPYR). For the Bangladesh case this was set to FALSE which means its using a 365 days/year calendar, while glofrim always assumes a calendar with leap years to convert the internal CMF time (minutes from 01-01-1850) to python datetime. For now the easy fix is to run the Bangladesh case with LLEAPYR=.True.

In any case we need to:

• double check the default way the models deal with leap years and whether this is dependent on a setting (@ChippChapp @hii600 @DirkEilander )
• know for all models what the current setting/default is (@DirkEilander )
• check at initialization whether this setting is the same across all models (@DirkEilander )

In case we allow for a 365 days/year calendar we need to additionally:

• adapt the datetime library to ignore Feb 29 in leap year (perhaps this already exists)

[JannisHoch]

Hi Dirk,

for now I think we should not allow for leap years due to limited time but on the long run we can think of a way to accomodate this.

I will check with Rens & Edwin how PCR deals with leap years and update you asap.

Assuming that all models besides CMF work with leap years, I think we should pick the lowest hanging fruit and just add some clear warning messages if CMF is run without leap years.

UPDATE:
PCR follows the Gregorian calender and thus cannot be run without leap years.
In case input data has no leap years and a day (29 Feb) is missing, PCR uses the data from the previous time step.

[JannisHoch]

Brief update on the CMF model: when specifiying leapyears as TRUE in the nam-file, there is no a priori updating to the start date anymore.

[DirkEilander]

I'm not sure, but i think you mean that the GLOFRIM time and CMF output timesteps are in sync if you set leapyears to TRUE?

For documentation: @ChippChapp had found that PCR always in uses leapyears. If the input does not contain data on Feb 29, it reuse the input data of Feb 28.

I suggest to postpone this feature request (a check on leap year setting consistency across the models) to the next verion.

[JannisHoch]

"I'm not sure, but i think you mean that the GLOFRIM time and CMF output timesteps are in sync if you set leapyears to TRUE?"

I was referring to the unexpected updating of CMF time to GLOFRIM start time before coupled run commences which was related to the fact that leap years were turned off in CMF. If turning setting on, everything works as expected.

"I suggest to postpone this feature request (a check on leap year setting consistency across the models) to the next verion."

Agree. For now, a simple warning (and exit?) should do.