track the coupling fluxes separately, to avoid confusion before/after scale_fluxes about cice

[czender]

That looks right to me. If I understand logic then flwup_ai in history is (flwout/aice)*aice. A minor point is that floating point arithmetic does not guarantee that (flwout/aice)*aice == flwout. Thus splitting flwout into two versions, one for the coupler and the other for internal use and history would improve the BFBness of history archived in double precision (default in MPAS?).

[dabail10]

I think we should have a conversation about this. It has just come up again in the context of the ponds. So, the pond fraction is:

apond = sum(apondn(n)*aicen(n)), n = 1, ncat

However, there is a history variable apond_ai. That is, we take apond*aice. However, do we ever divide apond by aice in the code? If not, that means apond_ai has aice multiplied twice effectively. We have a couple variables like this that are not sent to the coupler and hence are not scaled.

[dabail10]

Note that I am using apondn as the short form for trcrn(:,:,nt_apnd,:,:) here.

[czender]

Pinging @zswolff

[dabail10]

Actually, when level ponds are turned on then apond and apond_ai are:

     if (f_apond(1:1)/= 'x') &
         call accum_hist_field(n_apond, iblk, &
                        trcr(:,:,nt_alvl,iblk) * trcr(:,:,nt_apnd,iblk), a2D)
     if (f_apond_ai(1:1)/= 'x') &
         call accum_hist_field(n_apond_ai, iblk, &
                        aice(:,:,iblk) &
                      * trcr(:,:,nt_alvl,iblk) * trcr(:,:,nt_apnd,iblk), a2D)

[eclare108213]

I'm not seeing the problem here. E.g. at the end of compute_ponds_lvl, the tracer array is reloaded correctly:

apnd = apondn / (aicen*alvl_tmp)

That's also done for the cesm and topo cases. History uses the tracer fields directly, as you note above, and there's a special subroutine for merging (aggregating) tracer fields based on their dependencies. Can you be a little more specific about what you are looking at in the code?

[dabail10]

Thanks for highlighting this. I guess I didn't realize that this was done in the melt pond code. I do think it is worth making sure all of our _ai and non _ai fields are done correctly.

[dabail10]

Actually, I looked at the aggregate subroutine which does indeed aggregate (merge) the tracers according to their dependencies. For example for the level ice:

atrcr(:,:,:) = atrcr(:,:,:) + trcrn(:,:,nt_apnd,:,n)*trcrn(:,:,nt_alvl,:,n)*aicen(:,:,:,n)

However, I don't see where trcr(:,:,nt_apnd,:) is divided by the gridcell trcr(:,:,nt_alvl,:) and aice(:,:,:). Then it is multiplied by these in history ... I'm very confused.

[eclare108213]

I'm still not sure what you're looking at. There are two aggregate routines now, aggregate_area (which only does area, not tracers) and icepack_aggregate, which does everything. The division is done in another routine called at the end of icepack_aggregate, subroutine icepack_compute_tracers.

Which version of the code are you looking at? I'm not finding the line of code above:
bash-3.2$ grep -R "atrcr(:,:,:) = atrcr(:,:,:) + trcrn" cicecore/* icepack/*
bash-3.2$

Also, the history output uses the trcr arrays directly, not atrcr.

[apcraig]

This has come up yet again in #764. Cleaning up the coupling/non-coupling fields/fieldnames should be a higher priority. In #764, we have decided to use _iavg to indicate a field that is "per ice area" (divided by aice). We'll want to go thru the code carefully to instantiate new fields with the suffix _iavg, refactor subroutine scale_fluxes, and then review where those fields are used elsewhere in the code.