Update IS_IN_UNGRID to handle if grid lon defintions are mismatched

[JessicaMeixner-NOAA]

Pull Request Summary

Update IS_IN_UNGRID to handle if grid lon defintions are mismatched

Description

This PR adds a modified longitude point for the point that you are trying to find in a triangle element. If for example this point is -180 but the grid is defined from 0 to 360 this will address this mismatch and the point will be found in an element.

If there are regtests where the requested point output does not match the grid definition (ufs1.1) then there will be answer changes. This followed the work of the "fix periodicity" routine.

Issue(s) addressed

Fixes #1273

Commit Message

Update IS_IN_UNGRID to handle if grid lon defintions are mismatched

Check list

• Branch is up to date with the authoritative repository (NOAA-EMC) develop branch.
• Checked the checklist for a developer submitting to develop.
• If a version number update is required, checked the updating version number checklist.
• If a new feature was added, a regression test for testing the new feature is added.

Testing

• How were these changes tested? regression tests
• Are the changes covered by regression tests? (If not, why? Do new tests need to be added?) yes
• Have the matrix regression tests been run (if yes, please note HPC and compiler)? hera, intel
• Please indicate the expected changes in the regression test output, (Note the list of known non-identical tests.)

We expect that unstructured grid regtests with points defined outside of it's domain definition, such as ufs1.1 will have answer changes.

• Please provide the summary output of matrix.comp (matrix.Diff.txt, matrixCompFull.txt and matrixCompSummary.txt):

**********************************************************************
********************* non-identical cases ****************************
**********************************************************************
mww3_test_03/./work_PR1_MPI_e                     (1 files differ)
mww3_test_03/./work_PR3_UNO_MPI_e                     (1 files differ)
mww3_test_03/./work_PR2_UNO_MPI_d2                     (16 files differ)
mww3_test_03/./work_PR1_MPI_d2                     (11 files differ)
mww3_test_03/./work_PR3_UNO_MPI_d2_c                     (16 files differ)
mww3_test_03/./work_PR3_UQ_MPI_d2_c                     (16 files differ)
mww3_test_03/./work_PR3_UNO_MPI_d2                     (19 files differ)
mww3_test_03/./work_PR2_UQ_MPI_d2                     (15 files differ)
mww3_test_03/./work_PR3_UQ_MPI_e                     (1 files differ)
mww3_test_03/./work_PR3_UNO_MPI_e_c                     (1 files differ)
mww3_test_03/./work_PR3_UQ_MPI_d2                     (16 files differ)
mww3_test_09/./work_MPI_ASCII                     (0 files differ)
ww3_tp2.10/./work_MPI_OMPH                     (7 files differ)
ww3_tp2.16/./work_MPI_OMPH                     (4 files differ)
ww3_tp2.21/./work_ma                     (3 files differ)
ww3_tp2.21/./work_mb                     (3 files differ)
ww3_tp2.6/./work_ST4_ASCII                     (0 files differ)
ww3_ufs1.1/./work_unstr_b                     (4 files differ)
ww3_ufs1.1/./work_unstr_a                     (5 files differ)
ww3_ufs1.1/./work_unstr_c                     (4 files differ)
ww3_ufs1.3/./work_a                     (3 files differ)

Not originally expected non-b4b:

ww3_tp2.21/./work_ma                     (3 files differ)
ww3_tp2.21/./work_mb                     (3 files differ)

Looking into this test case closer, it looks like we're actually finding more points for the interpolation. This test might actually need further investigation (unrelated to this PR) as the interpolated output doesn't seem quite right. However it's the same before and after this PR, but the weights are slightly different.

The ufs1.1 tests now have more output points - indicating this fix is working.