Fix gcylc zero division error from task mean elapsed time #2586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
An (internal Met Office operational) user has noticed a traceback dialog in the GUI:
A brief look at the code reveals this is due to tasks which have a mean elapsed time value of zero - quite how this has occurred in a real suite is still a bit of a mystery to me and while the fix was trivial and the logic easy to follow, the difficultly here was reproducing the error (for self-review purposes) i.e. setting up a suite so that at least one task would have mean elapsed time of zero.
Eventually I just did a bodge job, so (unless you can easily come up with a more clever idea!) to recreate, just change line 240 to
meant = 0.0
and theif tnow > tetc_unix
statement on line 253 toif False
to automatically proceed to read the line in question, then run some suite with at least one task with scriptsleep 10
or similar that cycles at least once (someant
gets re-computed).N.B. there is some logic on 280:283 which does change
meant
to1
if it is in fact0
and I initially tried essentially moving that above the conditionals in question so the zero division error would not ever get raised, but it does influence the conditional on 261:264 so this simple change seemed more appropriate.