ATM needs to export coupling fields to mediator with correct sign or unit

[DeniseWorthen]

Description

Currently specialized code is required in CMEPS because the export fields obtained from the ATM do not have the correct sign or unit. For example, MOM6 requires the evaporative flux, not the latent heat flux, and so specialized code is required in CMEPS just to change the sign and unit. In addition, the momementum stresses and sensible heat flux also need a sign change within CMEPS. See NOAA-EMC/CMEPS#93

Solution

In atmos_model.F90, both sign and units can be changed using the optional scale_factor argument. For example,

	    ! MEAN Zonal compt of momentum flux (N/m**2)
            case ('mean_zonal_moment_flx_atm')
              call block_data_copy(datar82d, GFS_data(nb)%coupling%dusfc_cpl, Atm_block, nb, scale_factor=-rtime, rc=localrc)

Alternatives

Maintain existing code

Testing:

I have a working branch which is B4B with current baselines with the exception of the mediator restart files (ie, the data is the same, but with an opposite sign).

However, this method does change the value of the "non-valid" value in the exported fields. Currently, these non-valid values are typically 1.385E+34. An optional masking value could be used in the block_data interfaces to keep the values the same. I need to know where this value of 1.385E+34 is set however.

[DeniseWorthen]

The value of 1.385E+34 is actually the value of huge/dt_atmos, which makes sense for export fields using the optional argument scale_factor=rtime. So the "non-valid" value is already being altered during the block_data call.

The logic in the block_data interfaces has the scale_factor as an optional argument. I think that when scale_factor is provided, it should also check first if the source data value is a special value; if not, then scale the value. This could be done by adding an additional argument of huge when scale_factor is used.

[DeniseWorthen]

@junwang-noaa I've been thinking more about the issue of not scaling the special values in an export field. Right now, scale_factor is an optional input for all the block_data_copy procedures. It scales the output regardless of any special value on the input.

One option is to remove scale_factor as an optional argument where it exists and instead create a new procedure
block_copy_spval_1d_r8_to_2d_r8 where both scale_factor and spval would be non-optional arguments:

  subroutine block_copy_spval_1d_r8_to_2d_r8(destin_ptr, source_ptr, block, block_index, scale_factor, special_value, rc)

This would mean that if you want to scale the output, you must provide the value where the scaling is not applied.

No one is calling the block_copy with a scale_factor right now except for the filling of the "mean" export states for the coupled case.

[junwang-noaa]

I think that might be a better approach.