ESMF cap error with UFS debug options -init=snan,arrays

[MatthewMasarik-NOAA]

Describe the bug
When running UFS in debug mode coupled to WW3, if the WW3 compile uses the UFS flags (+ "-init=snan,arrays"), then the run will crash during initialization due to a 'floating invalid' error in the ESMF cap.

To Reproduce

• From ufs-weather-model select a run with S2SW compile and DDEBUG=ON.
• In cmplr.env:
  • replace the optc assignment to WW3 debug options, with an assignment to the UFS + "-init=snan,arrays" options, i.e., optc="$optc -O0 -check -check noarg_temp_created -check nopointer -warn -warn noerrors -fp-stack-check -fstack-protector-all -fpe0 -debug -ftrapuv -init=snan,arrays". (Fig 1)
  • Comment out the optimization and debugging blocks accordingly so the debug options will automatically be assigned to optc. (Fig 1)
  • Bypass a false error during the build of ww3_grid where the error checking is tripped by the substring 'error' in the filename scrip_errormod.F90, by replacing the err_pattern just below the header from err_pattern='error' to err_pattern='[[:space:]]error[[:space:]]'. (Fig 2) @JessicaMeixner-NOAA discovered this bug and the reason it occurs. This is a temporary fix that requires error to have some type of space (space, tab, end of line, carriage return) around it, so it will not get flagged if it is in a filename or part of a variable name, etc. This error is expected to go away when the CMAKE build system is complete.

Expected behavior

• The compile will succeed.
• The run will fail during initialization when a forrtl: error (65): floating invalid error in wmesmfmd.F90 causes the UFS simulation to terminate. (Fig 3)

Screenshots

Fig 1

Fig 2

Fig 3

Additional context

• N/A

[MatthewMasarik-NOAA]

Update: The false positive error mentioned above no longer occurs. The fix (PR#555) shown in Fig 2. above was merged into develop.

[DeniseWorthen]

@MatthewMasarik-NOAA I wonder if you've tried to compile in debug mode after the cmake build was added to WW3. What I found is that the -DDEBUG=YES compile option for S2SW conflicts w/ various instances of the variable DEBUG in WW3. This appears to occur at the time of processing CPP flags. For example, on hera:

/apps/intel/parallel_studio_xe_2018.4.057/compilers_and_libraries_2018/linux/bin/intel64/fpp -DDEBUG=YES  w3gsrumd.F90>tmp.F90

shows the following replacement

!/
!/ ------------------------------------------------------------------- /
!/
      FUNCTION W3GSUC_PTR_R4( IJG, LLG, ICLO, XG, YG, &
                              NCB, NNP, YES ) RESULT(GSU)
!     Single precision pointer interface
      TYPE(T_GSU)         :: GSU
      LOGICAL, INTENT(IN) :: IJG
      LOGICAL, INTENT(IN) :: LLG
      INTEGER, INTENT(IN) :: ICLO
      REAL(4), POINTER    :: XG(:,:)
      REAL(4), POINTER    :: YG(:,:)
      INTEGER, INTENT(IN), OPTIONAL :: NCB
      INTEGER, INTENT(IN), OPTIONAL :: NNP
      LOGICAL, INTENT(IN), OPTIONAL :: YES

This pre-preprocessed code then fails at compile time.

Note what I actually found in the compile log is that the instances of DEBUG were replaced by "1".

You can see a temporary fix which allowed me to compile using -DDEBUG=YES on cheyenne.intel DeniseWorthen@40940b6

[MatthewMasarik-NOAA]

Hi @DeniseWorthen , I haven't compiled in debug since CMAKE was added. I will look into it and reply back.

[DeniseWorthen]

I've created a UFS issue (ufs-community/ufs-weather-model#1133) since I'm unsure of where the fix will need to be made (UWM or WW3).

[DeniseWorthen]

@MatthewMasarik-NOAA I believe this issue can be closed. It looks like the fix was committed in ufs-community/ufs-weather-model#1130

[MatthewMasarik-NOAA]

Hi @DeniseWorthen, I'm working to verify this. Stayed tuned.

[MatthewMasarik-NOAA]

This issue can be closed as it has been resolved for S2SWA. Thank you @DeniseWorthen.