Open kdraeder opened 3 months ago
just a heads up for anyone looking at the branch calendar_loops
https://github.com/NCAR/DART/compare/calendar_loops...main calendar_loops is branched before the quantile_methods release.
I did not look through time_manager_mod for more examples of these extra loops, or suboptimal use of calendar types.
Describe the bug
The time_manager subroutines set_calendar_type_string and get_calendar_string give the right answers, but the loops over the calendar types (0,...,max_type) are unneeded and can be confusing.
To see the bug, put print statements in the loops that show the loop index and the input and output variables. Build and run a program that handles calendars; filter, model_mod_check, ...
In set_calendar_type_string the loop exits after the 0th iteration if it matches a calendar, or it tries to match the same cstring 6 more times before exiting. In get_calendar_string there's a similar loop over calendar types, where the outcome is known after the 0th iteration, but it goes on to do the same test 6 more times.
Error Message
See your messages from the suggestion above here.
Which model(s) are you working with?
model_mod_check
Screenshots
Version of DART
v9.12.refactored-1264-g38f4139ba
Have you modified the DART code?
Only to print messages. I committed those to branch calendar_loops.
Build information
Please describe:
gfortran, but this will happen with any compiler (unless it recognizes a spurious loop)
The intention may have been to have an array of calendar_types(0:max_type), then use variable calendar_type to access an element of it without the explicit if-blocks, but somehow that was not implemented, or was partially removed. Removal of the loops would be a simple fix. Implementation of the calendar_types array would be more involved, but would probably result in smaller or more elegent code. That might be an opportunity to make NO_CALENDAR = 0 and let actual calendars have 1,...,max_type