Create ESMF field attributes using the same kind as field data values

[DusanJovic-NOAA]

Description

This PR updates add_field_to_bundle subroutine in driver/fvGFS/fv_nggps_diag.F90. The values used for esmf field attributes (_FillValue and missing_value) must be the same real kind as the field data values, in this case REAL(4) in order to avoid type mismatch checks in PIO library which is used by ESMF I/O module.

See: ufs-community/ufs-weather-model#1564

How Has This Been Tested?

Full usf-weather-model regression test on Hera.

Checklist:

Please check all whether they apply or not

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[laurenchilutti]

HI @DusanJovic-NOAA is there anyone from EMC or the UFS community that you would like to review this?

[junwang-noaa]

@DusanJovic-NOAA Since the data buffer is in real(4) for dyn history outputs, can we just change line #106 to real(4)?

[DusanJovic-NOAA]

@DusanJovic-NOAA Since the data buffer is in real(4) for dyn history outputs, can we just change line #106 to real(4)?

missing_value is also used in other subroutines like hailcast_init and register_diag_field and the corresponding dummy arguments are declared as default real (either 4-byte or 8-byte depending on the compile options). So if we explicitly declare missing_value as real(4) that will introduce argument mismatch.

[junwang-noaa]

I see. The changes look good to me.

[jkbk2004]

@laurenchilutti @bensonr all tests at ufs-community/ufs-weather-model#1566 are done. Can you go ahead to merge in this pr?