CAM history erroneously overrides averaging flags for nhtfrq=1

[peverwhee]

What happened?

If nhtfrq=1, CAM history currently overrides (since cam6_3_140) the averaging flag to 'I'

    !
    ! Initialize history variables
    !
    do t=1,ptapes
      do fld=1,nflds(t)
        if (nhtfrq(t) == 1) then
           ! Override any non-I flags if nhtfrq equals 1
           tape(t)%hlist(fld)%avgflag = 'I'
        end if
        if (tape(t)%hlist(fld)%avgflag .ne. 'I') then
           hfile_accum(t) = .true.
        end if

BUT:
as @adamrher pointed out, this neglects subcycling averages.

What are the steps to reproduce the bug?

Run CAM, outputting a variable that exists in a subcycle (like a CLUBB variable in the macmic loop) with the 'A' flag and observe that the results are the same as for the 'I' flag.

What CAM tag were you using?

cam6_4_032

What machine were you running CAM on?

CGD machine (e.g. izumi)

What compiler were you using?

GNU

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Any CAM SE can do this

Extra info

No response

[gold2718]

This happened in #903, see this comment.

[adamrher]

Is there a way to query how many times an outfld call for a particular variable is called in a time-step? If we could get this number N than we could make logic that, for this special case of nhtfrq=1 and avgflag_pertape='A', forces all N=1 variables into the 'I' tapes and the N>1 variables into the 'A' tapes (and adjust their metadata accordingly).

[gold2718]

I would vote for a new, optional input to addfld to indicate this type of field. Something like sampled_on_subcycle or allow_single_timestep_average.

[adamrher]

One complication with that approach is I could set up the namelists to do no subcycling -- e.g, for ne240pg3, we don't subcycle in the macmic loop at all.

[gold2718]

One complication with that approach is I could set up the namelists to do no subcycling -- e.g, for ne240pg3, we don't subcycle in the macmic loop at all.

Of course but is that a bad thing? What is the impact of allowing averaging (or other collection methods) for this case? Is there an impact beyond the timestamp being in the middle of the time step instead of the current time (lines 5816 - 5822) in cam_history.F90)?

[adamrher]

I don't know if there's an adverse impact other than creating inconsistent time metadata relative to the non-subcycled variables in this case, but I agree this is preferable to the current method.