Mapping ATM states-> ICE bilinearly

[DeniseWorthen]

This is essentially a follow-on issue to the original Issue #38, but I'm opening a new issue to clarify the relationship between bilinear mapping, masking and ESMF version.

The initial issue was noted in March 2021. At that time, there was no component model which had fields being mapped bilinearly. The stripe issue (see #38 (comment)), was first noticed as being triggered when changing a single mapping from mapconsf --> mapbilinear. The current S2SW case does have fields which are mapped bilinearly for the WAV component.

The issue lay dormant until late 2024, when the stripes issue was seen during development of the LND component model. At that point, a bug fix was found in ESMF and committed in 8.8.0b04.

Testing 8.8.0b10 against the current version used in UWM (8.6.0) for C48-5deg and C96-1deg (S2S) and C96-1deg (S2SW) has shown the following:

1. For both the S2S and S2SW cases, v8.6.0 is B4B with v8.8.0b10. That means that in the UWM currently, the stripes bug is unexposed for the global coupled model.

2. Using ESMF86, stripes can be generated in the RegridStatus field if the srcMask for the ATM is changed from 1 to ispval_mask. This mask change will map the entire ATM domain (instead of masking out the source field where mask=1). No change in the mapping types is required.

   However, the stripes only occur if there is a bilinearly mapped field present. So it does not occur, for example, in the S2S case (based on testing at C48-5deg, C96-1deg) but does occur in the S2SW case (based on testing at C96-1deg).

   Using ESMF8.8.0b10, changing the ATM srcMask does not generate stripes in the RegridStatus field.

3. Mapping the ATM states to the ICE bilinearly appears to resolve the majority of the grid imprint issue (Grid imprinting when running C192 atmos with 1/4 deg ocean and seaice ufs-community/ufs-weather-model#2466 (comment)). However, this mapping requires that the ATM srcMask be set to ispval_mask (see figure in Sync w/ latest ESCOMP/main #129).

4. When triggered in S2SW + ESMFv8.6.0, the stripes are associated with 2 points which are reported as being mapped OCN->ATM, even though the land_frac=1 at these points. This figure show the RegridStatus field for C96-1deg S2SW, ATM srcMask=1 for ESMF8.6.0 (left) and ESMF8.8.0b10 (right) and the location of the two points which are falsely mapped in the 8.6.0 case. These two points lie on stripes. With the fix, the two points are characterized by RegridStatus=0, which is correct for these points ("The destination location is masked; no regridding").

   It turns out that the mapping of these two points to the ATM does not change answers (based on 3hour S2SW C96-1deg). In other words, S2SW+8.6.0+mask change is B4B with S2SW+8.8.0b10+mask change for the forecast fields, although differences do show in the mediator history files.

5. The mask change alone is expected to change answers, since the mix of points use as source points will change. For ESMF8.6.0, these tests indicate that the stripes themselves do not also contribute to B4B changes. It is possible that higher resolutions might not behave in the same way.

Conculsion

1. In order to mitigate the grid imprint problem, the ATM states should be mapped to ICE bilinearly.
2. The srcMask for the ATM will need to be changed from 1->spval_mask
3. It is probably better to wait for ESMF8.8.0b10 or higher, but 1) and 2) could be done at 8.6.0 with the understanding that B4B changes might be arising from more than just the mask change.