Closed billsacks closed 5 years ago
I'm starting to work on this one.
I see one problem already. build-namelist has a hard-coded assumption that years in RUN_STARTDATE are going to be exactly 4 digits. This can be generalized in the perl code so that the number of digits for the year can be any length.
I'm not sure if this is the only problem here, but it's one problem.
Another problem is that the end year is hardcoded to 9999 for this case in the time-manager. So it'll stop rather than running.
select case (stop_option)
case ('never') !*** coupler or signal catcher stops glc
stop_iopt = stop_opt_never
iyear_end_run = 9999
@d80ngv (Sarah Bradley) ran into a problem when doing a run that extended past year 9999: In trying to restart from a file with year 10078:
I have a feeling this is due at least in part to limitations in glc_time_management.F90. I can't tell from Sarah's message if they changed everything that would need to be changed: doing a search for '4' in glc_time_management.F90 turns up many instances, including both lengths of character strings and the string_length argument in many int_to_char calls.
One possible approach, then, would be to make sure that glc_time_management gets all the changes it needs to support up to 6-digit years. Another approach (at least longer-term) is to just ditch this module and replace it with a functional time manager, given all of the other issues with this time manager.