mapping ATM state fields bilinearly

[DeniseWorthen]

Changes are required in esmFldsExchange_nems and med_map_mod to implement two changes: unity normalization and bilinear mapping of ATM state fields. These are changes from the current implementation in which the criteria used was validating the NEMS mediator functionality.

1. CMEPS has the ability to apply a "unity" normalization when mapping from source to destination grid. This ensures that the mapping weights on the destination side add to one. The normalization is a static field which needs to be calculated only once (in med_map_mod) by mapping a field value 1.0 from each source component to each destination component for each defined mapping type between those two components. The reciprocal of the mapped value 1.0 is added to the mediator internal state and used when specifying that the normalization type for mapping is "one"; e.g.

call addmap(fldListFr(source_component)%flds, 'field_name', destination_component, mapconsf, "one", 'unset')

Note that an equivalent process happens when normalizing using a time-varying ice fraction. In that case, the the normalization in the above call would be set to ifrac. When normalizing by ifrac, the mapped destination field (= mapped source_field*ifrac) is normalized by the factor 1.0/(mapped ifrac).

The ability to apply unity normalization when not normalizing by ifrac was not available in NEMS and so was set to none in the mapping calls used by UFS. Since it is a static field that is calculated only once, there is no penalty to applying the unity normalization and it ensures that the mapping weights always add to one regardless of the mapping type.

2. For CMEPS in UFS, ATM states (T,P,Q,U,V) are being mapped conservatively when mapped to the ICE (when coupled) or to the mediator (when using the mediator aoflux calculation). (The DATM application also maps the 2m and 10m state fields conservatively for use in the bulk flux option).

For the typical case in UFS, this means mapping from a coarse ATM to a fine OCN (relatively). This creates very un-smooth destination fields. For example, the following shows the mapped Tbot (from ATM) exported to the ICE in the C96-mx100 case in the Ross Sea (Antarctic) region. The left shows the conservatively mapped field and the right shows the bilinearly mapped field.

The following shows the value at the x=130 line:

Since ATM T,P,Q,U,V are global, unmasked states and not fluxes, the mapping should be switched to bilinear in order to provide smooth fields to the ICE model (coupled) and for the aoflux calculation (DATM). Changes are required to both esmFieldsExchange_nems (where the mapping is defined) as well as to the srcMaskValue used for a bilinear routehandle creation from ATM->OCN,ICE.

For the datm applications (either cdeps or nemsdatm), the ATM is much finer than the OCN. This results in smooth states being passed to the ICE and aofluxes even though they are being mapped conservatively.

[DeniseWorthen]

The bilinear mapping of ATM states when using the DATM component requires the addition of another mapping type.

For pure bilinear mapping, the dstStatus flag field returned from the RegridStore can have the value of 2 at points along the topmost row of the tripole grid. The value of 2 indicates that the destination location is outside the source grid, so no regridding has been performed on it.

The maximum latitude of the source grids are:

cfsr data source, max lat: 89.844
gefs data source, max lat: 89.821

The maximum latitude of the tripole destination grids are:

mx100 89.831 
mx050 89.881
mx025 89.939

Depending on source-destination pairs, destination locations can be unmapped because the source latitude range does not extend far enough north. So, for example, the cfsr data source can be mapped completely to the mx100 destination but the gefs data source cannot.

Introduction of a second bilinear mapping type which uses an extrapolation method of ESMF_EXTRAPMETHOD_NEAREST_STOD allows these points to be mapped. This method will fill any unmapped destination points with the closest source point

[DeniseWorthen]

The following shows the bottom temperature (Tbot) mapped from the CFSR data source to the mx025 destination grid using mapbilin only. Values near the pole which are unmapped are given a value of 0.0 and appear here as being <= 250.0K.

The following shows the same field using the current conservative mapping (left) and using bilinear mapping with NSTOD extrapolation to fill the umapped locations. This demonstrates both the unsmoothness of the conservative mapping fields and also that the bilinear NSTOD mapping fills the unmapped destination points with reasonable values.

[DeniseWorthen]

The switch to unity normalization will create b4b differences at the first coupling timestep. To asses the impact of the switch to unity normalization, a butterfly comparison test was carried out using the cpld_controlfrac_c192 test (which runs for 48 hrs). Three tests were run:

1. Current develop branch
2. Current develop branch + adding butterfly_effect = .T. to the fv_core_nml
3. Current develop branch but switched to a CMEPS branch using unity normalization for all fields: shown here. In this test case, nems.configure contained the setting norm_mode=one.

Difference fields were made for SST for the ocean and Tsfc for the ice after the 48 hour run. Visual comparisons indicate that the b4b differences associated with unity normalization are comparable to the butterfly effect.

[arunchawla-NOAA]

@DeniseWorthen the PRS related to this issue are already merged. Is this issue still need to be open ?

[DeniseWorthen]

The bilinear mapping is still an outstanding issue. I believe we should be mapping states bilinearly and fluxes conservatively. The fact that we're mapping states conservatively is a hold-over from the NEMS mediator prior to the implementation of the fractional grid.

The issues is that when we map states conservatively, we get the imprint of the ATM resolution on the OCN and ICE as shown in the first few figures above. This is even more of an issue when I've tested a c96mx025 configuration for the validation of the XGrid. In that case, this "imprint" appears even in mid and low latitudes.

I have not moved forward on this because of an issue I saw when adding bilinear mapping. In ESMF, we can obtain the dstStatusField during RH creation which reports a flag for how each destination point was arrived at. The various possible values are shown here.

Using the dstStatusField, I had found that in UFS, when I made a single mapping change (mapping Sa_pslv from atm->ocn bilinearly instead of conservatively), I saw a strange effect on a completely different mapping, in this case the mapping of ocn->atm with conservative destination. A few points were showing up as now being mapped from ocn->atm, when previously they had not been.

This is the dstStatusField for ocn->atm conservative mapping:

This is the same field if I change the sea level pressure to bilinear mapping atm->ocn. Note that the stripes actually all run the same direction, but because some FV3 tiles are laid out sideways, the direction appears to change. In any case, there are now a handful of points which are now being mapped from ocn->atm. I believe all these points are all land points on the atm side.

Recently, I found that if map the sea level pressure from atm->ocn bilinearly and set the dstMaskValue = ispval_mask when mapping from ocn->atm, the issue does not arise:

I've been in contact w/ Rocky and Bob regarding this issue, but so far we don't have an explanation for the odd behavior. For that reason, I've been reluctant to implement bilinear mapping even though I think it is the right thing to do.

[DeniseWorthen]

Changed title of issue since unity normalization was committed in UFS PR #522