recursive timer calls to CPL:RUN

[worleyph]

In cime/src/drivers/mct/main/cime_comp_mod.F90 is logic of the form:

     call t_drvstartf ('CPL:ATMOCN1',cplrun=.true.,barrier=mpicom_CPLID,hashint=hashint(4))
  ...
     if (do_budgets) then
  ...
        call t_drvstartf ('CPL:BUDGET0',cplrun=.true.,budget=.true.,barrier=mpicom_CPLID)
  ...
        call t_drvstopf ('CPL:BUDGET0',cplrun=.true.,budget=.true.)
     endif
  ...
     call t_drvstopf  ('CPL:ATMOCN1',cplrun=.true.,hashint=hashint(4))

and also later in the code for the timers 'CPL:ATMOCNP' and 'CPL:ATMOCN2 (all for 'CPL:BUDGET0').

With cplrun=.true., 'CPL:RUN' t_startf is called twice before 'CPL:RUN' t_stopf (twice), resulting in a "recursive" call. This does not seem to do any harm - GPTL can handle this - but I doubt that this was intended. I would like the developers who added the do_budget code to revisit this and determine whether this was intentional. (The fix is to remove 'cplrun=.true.' from the calls to

 call t_drvstartf ('CPL:BUDGET0',cplrun=.true.,budget=.true.,barrier=mpicom_CPLID)
 call t_drvstopf ('CPL:BUDGET0',cplrun=.true.,budget=.true.)

in these three situations.

Not sure who can respond to this, but since it is in CIME, am assigning @jgfouca initially (sorry Jim).

[jgfouca]

Going to pass this hot potato to @rljacob

[worleyph]

@rljacob , did you ever hear back from the do_budget developers? Should I submit a PR to make the change that (I think) is needed?

[rljacob]

No I did not. Is that logic still there?

[worleyph]

Yes.

[amametjanov]

Does the recursive call cause a memory (runaway) leak? The run_e3sm script for high-res runs turns this on:

xmlchange --id BUDGETS --val TRUE

whereas runs with create_test/create_newcase do not.

[worleyph]

No - it is innocuous. GPTL can handle "recursive" calls (just nested calls of timers with the same name), but it silly to have this as a recursive call and it makes the timing output a little misleading.