Update dev/ufs-weather-model to fix warnings and add develop

[JessicaMeixner-NOAA]

Pull Request Summary

This addresses multiple warnings for GFSv17

Description

This PR merges in develop which:
-- Change grib2 packing from JPEG to Complex (@sbanihash ) #1496
-- multipleupdates to remove remarks when compiling in debug mode @mingchen-NOAA
-- fixes for warnings/errors in ww3_grib2 and ww3_gint @mingchen-NOAA
-- other updates from Develop
-- Includes fixes from @NickSzapiro-NOAA :
--- include mpi.h to use mpi_f08 (merged from develop) + updates to mesh-cap
--- Consistent character(len=80) :: stdname #1433
--- Use ymd instead of uninitialized date in timeInit for (unused?) optDate in alarmInit #1423

Issue(s) addressed

none specifically but solves multiple for dev/ufs-weathe-rmodel branch.

Commit Message

Merging of multiple PRs and develop to address warnings and bugs

NOTE: don't forget to use merge commit. Do NOT squash merge this PR!

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

In progress, for both standalone ww3 and ufs-weather-model will update when done & create ufs-weather-model PR.

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

[NickSzapiro-NOAA]

The use of external declarations are my main reservation, as compiler will not check whether subroutine and calling signatures match. So, developer must get these right (even if they change) and may get runtime rather than compile issues.

[JessicaMeixner-NOAA]

We had one issue with one external declaration causing issues w/GNU. @mingchen-NOAA is fixing that now.

@mingchen-NOAA added those to address compiler warnings he saw on wcoss2 -- Is there a better way to remove that warning? I don't know if Ming still knows the exact one.

[mingchen-NOAA]

@NickSzapiro-NOAA @JessicaMeixner-NOAA I recall that the warning from the Intel Fortran Compiler (warning #8889) was about explicitly declaring the EXTERNAL attribute for external procedures.

[NickSzapiro-NOAA]

Best is to use them from a module.

Second best is to make an explicit interface. Where do these come from?

I see external declaration as the quickest fix but most prone to errors

[mingchen-NOAA]

@NickSzapiro-NOAA @JessicaMeixner-NOAA I reproduce these warnings. This is an example:

/scratch4/NCEPDEV/marine/Ming.Chen/global-workflow/ursa/rmRemks/sorc/ufs_model.fd/WW3/model/src/w3profsmd.F90(1212): warning #8889: Explicit interface or EXTERNAL declaration is required.   [ILU0]
    CALL ILU0  (NX, ASPAR, JAA, IAA, AU, FLJAU, FLJU, IWKSP, IERROR)
---------^

[JessicaMeixner-NOAA]

@mingchen-NOAA - Maybe the best thing to do for now, is in addition to the fixes that you have for abort -> call excede, that we remove all references to abort and maybe delete a few of the extra lines Nick has commented here.

Then we can allow this PR to move forward, and we can circle back to addressing these warnings in a different way. I didn't catch this sooner, but some of these look like maybe a different solution to remove the warning would be the way to go. I can help strategize different fixes next week. If this PR hasn't been merged, we can add it here, if not we'll make another PR.

[mingchen-NOAA]

Best is to use them from a module.

Second best is to make an explicit interface. Where do these come from?

I see external declaration as the quickest fix but most prone to errors

@NickSzapiro-NOAA
PDLIB/yowpdlibmain.F90 external :: SCOTCH_PARMETIS_V3_PARTGEOMKWAY from SCOTCH (or ParMETIS) library
ww3_grib.F90: EXTERNAL from NCEP library routines
w3profsmd.F90 some from subroutines defined in this file but outside the module (after end module). I can put these inside the module. But one solver I cannot find where it comes from.

[NickSzapiro-NOAA]

fwiw, Gemini gives this untested explicit interface for SPARSKIT solver:

      INTERFACE
         SUBROUTINE SOLVER(N, RHS, SOL, IPAR, FPAR, W)
            IMPLICIT NONE
            
            ! --- Problem Size ---
            INTEGER, INTENT(IN) :: N               ! System size (number of unknowns)
            
            ! --- Primary Vectors ---
            ! Note: Using REAL(8) is the modern equivalent of REAL*8
            INTEGER, PARAMETER :: DP = KIND(0.0D0)
            
            REAL(KIND=DP), DIMENSION(N), INTENT(IN) :: RHS    ! Right-hand side vector (RHS)
            REAL(KIND=DP), DIMENSION(N), INTENT(INOUT) :: SOL  ! Solution vector (input initial guess, output solution)
            
            ! --- Control & Work Arrays ---
            INTEGER, DIMENSION(16), INTENT(IN) :: IPAR        ! Integer parameters (Fixed size 16)
            REAL(KIND=DP), DIMENSION(16), INTENT(IN) :: FPAR  ! Double precision parameters (Fixed size 16)
            REAL(KIND=DP), DIMENSION(*), INTENT(INOUT) :: W   ! Work array (Assumed-size, size determined by IPAR(14) or similar)

         END SUBROUTINE SOLVER
      END INTERFACE

[mingchen-NOAA]

@NickSzapiro-NOAA Thank you Nick! I will try it.

[JessicaMeixner-NOAA]

FYI @NickSzapiro-NOAA - your comments/concerns have been addressed in #1512 which as soon as we merge it to develop (so the fixes are available for all, we'll merge in here and then I think tests should pass and I should be able to open a ufs-weather-model PR.

[JessicaMeixner-NOAA]

This PR has been updated with fixes from develop to address GNU issues and reviewer comments. UFS regtests have passed, but I"m going to run a cleaner test before opening the UFS PR. Feel free to review though.