by pass missing value of NaN

[weiyuan-jiang]

If the missing values is Nan, all the calculation will be Nan. It is not necessary to swap or test

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[weiyuan-jiang]

This PR is addressing the issue ufs-community/ufs-weather-model#1259

[mathomp4]

I can say this is zero-diff for a C24 run of GEOSgcm. I'll let @tclune or someone more knowledgable than I comment on the code change.

[tclune]

I don't see how this change has anything to do with NaN. The change merely verifies that if a fill is specified then it is of a numeric type. (I.e., it will ignore fills that are strings or bools.) What am I missing?

[weiyuan-jiang]

@bena-nasa , I think it is fine to bypass the Nan values even there is Nan. Any calculation relults that Nan is involved would be Nan too.

[weiyuan-jiang]

I don't see how this change has anything to do with NaN. The change merely verifies that if a fill is specified then it is of a numeric type. (I.e., it will ignore fills that are strings or bools.) What am I missing?

This line crashes without the fix.

MAPL/griddedio/GriddedIO.F90

Line 1092 in d46c2ed

call ESMF_AttributeGet(field,name=fill_value_label,value=fill_value,_RC)

I suspect this is a bug from ESMF. Just two lines above, I test the return type of the '_FillValue', it is ESMF_TYPEKIND_R4 , but ESMF crashes when trying to get it.

[weiyuan-jiang]

[tclune]

I don't see how your change would affect that case. R4 matches so has_missing_value should be .true. before and after your change. If the code change affects results, it seems to suggest memory corruption.

[weiyuan-jiang]

@bena-nasa , I think it is fine to bypass the Nan values even there is Nan. Any calculation relults that Nan is involved would be Nan too.

Our Metadata does not take "Nan" as a numerical type. So there is no missing data if it is Nan. I think it is fine because the results would be Nan if Nan is involved in the calculation

[weiyuan-jiang]

I have another theory. When ESMF checks the type of attribute '_FillValue', it actually checks the type of the variable. They are supposed to be the same type anyway. Whey trying to get it, it crashes because it is a string ( Nan or Nanf)

[tclune]

Your theory is plausible, but I still don't see how the changes here have any effect.

[weiyuan-jiang]

After my change, our program thinks there is no missing value if it is "Nan". So the above crashing line I showed you would not be executed.

[weiyuan-jiang]

pfio can set and get Nan attribute, but ESMF does not seem to work. But I think it is safe to by pass Nan.

[tclune]

See inline comment.

[weiyuan-jiang]

If regrid gets trouble when there is Nan, this PR won't work. Nan needs to be replaced somewhere.

[weiyuan-jiang]

I have verified this PR resolves the Nan issue from ufs @bena-nasa @tclune

[weiyuan-jiang]

@mathomp4 This CMakeLists.txt is working on Orion. If it is working here, lets merge it.

[mathomp4]

Okay. Let me make an update to CMakeLists.txt with a comment.

[mathomp4]

@tclune has approved. This is just a "re-approval" after my CMake comment.

[jkbk2004]

@mathomp4 are you going to release a new patched version of the mapl-2.21.3 out of this pr?

[mathomp4]

@mathomp4 are you going to release a new patched version of the mapl-2.21.3 out of this pr?

@jkbk2004 I think once we get in #1580, develop should be in a good place. But let me ping the team to see if anything else needs in. If not, I'll work on getting something out today (probably MAPL 2.22).