Change mapconsf mappings to mapconsd?

[billsacks]

Emerging from a discussion of ESCOMP/mizuRoute#426, I talked with @mvertens a bit about the use of mapconsf vs. mapconsd. I found an email from her from Nov, 2020 - where the context was some changes she was making to the lnd <-> glc mapping - where she said:

Actually, everything should be mapconsd (long story - I spent a week with Bob and Denise trying to sort this out). For CESM it is only round of level changes at most - but I am trying to add this back in incrementally as we move forwards and test.

However, it looks like many mappings still use mapconsf. I believe this is part of the problem behind ESCOMP/mizuRoute#426: the main lnd -> rof mapping is treated as mapconsf, but the lnd -> rof mapping of lfrac uses mapconsd, and this discrepancy means that the user-provided lnd -> rof mapping file is ignored for the mapping of lfrac.

This morning, @mvertens told me that, although she, @oehmke and @DeniseWorthen came to agree that we should be using mapconsd (at least for global grids), at the time they wanted to avoid answer changes (and/or didn't have time to do the full validation this would require), so they did not make this change. @mvertens and I felt like it would be worth revisiting this to answer the following questions:

1. Do we still agree that mapconsd should be used for all mappings? (I would like to understand this myself.)
2. Does this hold for regional grids as well as global grids?
3. For global grids, is it true that we just expect roundoff-level changes from this? Is that true for both CESM and UFS?
4. Is soon (say, within the next few months) a good time to make this change?

Things are pretty busy now both for @mvertens and the ESMF team, but maybe we could meet in a few weeks to discuss these things – or just have some discussion here.

[ekluzek]

@billsacks thanks for starting the discussion. I was going to create an issue for the mizuRoute problem, but this should cover it for us if we make this change. Those are the questions I want to know about as well, and right now I certainly do not.

Looking at the code the difference is in how the normalization is done. Here is med_map_mod.F90:

    else if (mapindex == mapconsf .or. mapindex == mapnstod_consf) then
       if (mastertask) then
          write(logunit,'(A)') trim(subname)//' creating RH '//trim(mapname)//' for '//trim(string)
       end if
       call ESMF_FieldRegridStore(fldsrc, flddst, routehandle=routehandles(mapconsf), &
            srcMaskValues=(/srcMaskValue/), &
            dstMaskValues=(/dstMaskValue/), &
            regridmethod=ESMF_REGRIDMETHOD_CONSERVE, &
            normType=ESMF_NORMTYPE_FRACAREA, &
            srcTermProcessing=srcTermProcessing_Value, &
            ignoreDegenerate=.true., &
            dstStatusField=dststatusfield, &
            unmappedaction=ESMF_UNMAPPEDACTION_IGNORE, &
            rc=rc)
       if (chkerr(rc,__LINE__,u_FILE_u)) return
       ldstprint = .true.
    else if (mapindex == mapconsf_aofrac) then
.
.
.
    else if (mapindex == mapconsd .or. mapindex == mapnstod_consd) then
       if (mastertask) then
          write(logunit,'(A)') trim(subname)//' creating RH '//trim(mapname)//' for '//trim(string)
       end if
       call ESMF_FieldRegridStore(fldsrc, flddst, routehandle=routehandles(mapconsd), &
            srcMaskValues=(/srcMaskValue/), &
            dstMaskValues=(/dstMaskValue/), &
            regridmethod=ESMF_REGRIDMETHOD_CONSERVE, &
            normType=ESMF_NORMTYPE_DSTAREA, &
            srcTermProcessing=srcTermProcessing_Value, &
            ignoreDegenerate=.true., &
            dstStatusField=dststatusfield, &
            unmappedaction=ESMF_UNMAPPEDACTION_IGNORE, &
            rc=rc)
       if (chkerr(rc,__LINE__,u_FILE_u)) return
       ldstprint = .true.

The difference is moving from normType=ESMF_NORMTYPE_FRACAREA to ESMF_NORMTYPE_DSTAREA. I would think this change would be greater than roundoff.

I think I'll need a temporary change for mizuRoute sooner than this change will happen so I'll make a separate issue for that.

[billsacks]

@mvertens just clarified: "in terms of roundoff - I was only using that term lightly. What I really meant is that answers should just have very little differences."