Error with walltimemax >= 24:00

[rljacob]

Originally reported by Pat Worley for CIME 5.2.0 in ACME. This line in config_batch for Titan:

<queue walltimemax="24:00" default="true">batch</queue>

Is now giving an error message:

 ./create_newcase -case FC5AV1C-L.ne30.CIME52.titan_pgi  -compset FC5AV1C-L -res ne30_ne30 -mach titan -compiler pgi -project cli115
 ...
 Could not find a queue matching task count 1280, falling back to deprecated default walltime parameter
 Traceback (most recent call last):
   File "./create_newcase", line 200, in <module>
     _main_func(__doc__)
   File "./create_newcase", line 183, in _main_func
     run_unsupported=run_unsupported)
   File "/autofs/nccs-svm1_home1/worley/ACPI/SVN/ACME/master/CHECK/ACME/cime/scripts/Tools/../../utils/python/CIME/case.py", line 735, in configure
     env_batch.set_job_defaults(bjobs, pesize=maxval, walltime=walltime, force_queue=queue)
   File "/autofs/nccs-svm1_home1/worley/ACPI/SVN/ACME/master/CHECK/ACME/cime/scripts/Tools/../../utils/python/CIME/XML/env_batch.py", line 219, in set_job_defaults
     self.set_value( "JOB_WALLCLOCK_TIME", walltime , subgroup=job)
   File "/autofs/nccs-svm1_home1/worley/ACPI/SVN/ACME/master/CHECK/ACME/cime/scripts/Tools/../../utils/python/CIME/XML/env_batch.py", line 43, in set_value
     t = time.strptime(value,"%H:%M")
   File "/sw/xk6/python/2.7.9/sles11.3_gnu4.3.4/lib/python2.7/_strptime.py", line 467, in _strptime_time
     return _strptime(data_string, format)[0]
   File "/sw/xk6/python/2.7.9/sles11.3_gnu4.3.4/lib/python2.7/_strptime.py", line 325, in _strptime
     (data_string, format))
 ValueError: time data '24:00' does not match format '%H:%M'

[rljacob]

Workaround found by @mfdeakin is to just reduce it to 23:59. But all agree max times of 24 or longer should be allowed.

[rljacob]

What is walltimemax for? For machines that don't have a walltimemax specified, users can set WALLCLOCK to 24 or more.

[mfdeakin-sandia]

Because this is a critical fix, the code for this is in the ACME repository, and will be merged with the next subtree split

[jedwards4b]

I'm concerned that this doesn't give us an opportunity to review the PR...

[rljacob]

The subtree split will be a PR. We don't have nearly as much stuff as the last time we brought over ACME changes.

[mfdeakin-sandia]

It's a concern of mine as well. I'm thinking of making a fake PR here for that purpose

[rljacob]

Fixe included in PR #1287