Floating point exception: phys/module_sf_noahmplsm.F at noahmp_sflx subroutine

[LluisFB]

Hi,

on my quest of compiling and running WRF v4.5.1 in debug mode, I encountered a new bug in phys/module_sf_noahmplsm.F at noahmp_sflx subroutine

The error message is:

(...)
Caught signal 8 (Floating point exception: floating-point invalid operation)
==== backtrace (tid:3940037) ====
 0 0x0000000000012cf0 __funlockfile()  :0
 1 0x0000000008b73314 module_sf_noahmplsm_mp_noahmp_sflx_()  /ccc/work/cont003/gen6877/fitabllu/WRF/v451_git_FPS/intel/20-0-0/netcdf_4-7-4netcdff_4-5-3/dmpar/WRFdbg/phys/module_sf_noahmplsm.f90:885
 2 0x0000000008a8acb1 module_sf_noahmpdrv_mp_noahmplsm_()  /ccc/work/cont003/gen6877/fitabllu/WRF/v451_git_FPS/intel/20-0-0/netcdf_4-7-4netcdff_4-5-3/dmpar/WRFdbg/phys/module_sf_noahmpdrv.f90:1140
 3 0x0000000008f6149c module_surface_driver_mp_surface_driver_()  /ccc/work/cont003/gen6877/fitabllu/WRF/v451_git_FPS/intel/20-0-0/netcdf_4-7-4netcdff_4-5-3/dmpar/WRFdbg/phys/module_surface_driver.f90:2984
(...)

Looking at line #885 of phys/module_sf_noahmplsm.f90, one encounters:

     IF((OPT_IRRM .EQ. 0) .AND. (SIFAC .EQ. 0.0) .AND. (MIFAC .EQ. 0.0) .AND. (FIFAC .EQ. 0.0) &
         .AND. (IRRFRA .GE. parameters%IRR_FRAC)) THEN
          SIFAC = 1.0
     END IF

I added some printing in the subroutine:

     PRINT *,'  Lluis OPT_IRRM',OPT_IRRM,' SIFAC', SIFAC, ' MIFAC', MIFAC, ' FIFAC', FIFAC, ' IRRFRA',&
       IRRFRA,' parameters%IRR_FRAC', parameters%IRR_FRAC
     IF((OPT_IRRM .EQ. 0) .AND. (SIFAC .EQ. 0.0) .AND. (MIFAC .EQ. 0.0) .AND. (FIFAC .EQ. 0.0) &
         .AND. (IRRFRA .GE. parameters%IRR_FRAC)) THEN
          SIFAC = 1.0
     END IF

and this is the result:

   Lluis OPT_IRRM           0  SIFAC  0.0000000E+00  MIFAC  0.0000000E+00  FIFAC
  0.0000000E+00  IRRFRA  0.0000000E+00  parameters%IRR_FRAC            NaN

As you can see parameters%IRR_FRAC is not properly initialized
Initialization of parameters%IRR_FRAC is done in subroutine TRANSFER_MP_PARAMETERS of phys/module_sf_noahmpdrv.F as:

(...)
    parameters%IRR_FRAC   = IRR_FRAC_TABLE      ! irrigation Fraction

The actual value of IRR_FRAC_TABLE is initialized in phys/module_sf_noahmplsm.F in subroutine read_mp_irrigation_parameters
at line #12206:

    IRR_FRAC_TABLE   = -1.0E36    ! irrigation Fraction

And then in line #12228 values are retrieved as a namelist parameter from MPTABLE.TBL file asIRR_FRAC

(...)
    inquire( file='MPTABLE.TBL', exist=file_named )
    if ( file_named ) then
      open(15, file="MPTABLE.TBL", status='old', form='formatted', action='read', iostat=ierr)
(...)
    read(15,noahmp_irrigation_parameters)
    close(15)
(...)
    IRR_FRAC_TABLE   = IRR_FRAC    ! irrigation Fraction

In the file, one encounters:

(...)
&noahmp_irrigation_parameters
IRR_FRAC   = 0.10       ! irrigation Fraction
(...)

My interpretation might be that reading of the MPTABLE file does not work in debug mode, but I might be wrong.

Thanks,

Lluís

 

[cenlinhe]

Thank you for reporting this. Did you make sure the MPTABLE file is in your run directory? I am not sure why the reading does not work in debug mode, which seems weird to me since these two are not related in the code.

 

[LluisFB]

Hi Cenlin,

Yes that was the first thing I checked. The MPTABLE file is there, otherwise it would had crashed due to the miss of the file.

I agree, it does not make sense that the reading of namelist does not work in debug compilation mode. For sure is that, in debug mode, we can not operate with 'NaN' variables, which it is not checked in production mode and for sure compiled with optimization > -O2

I realized that the call to read the irrigation parameters (subroutine read_mp_irrigation_parameters from phys/module_sf_noahmpdrv.F) is done within NOAHMP_INIT called in phys/module_physics_init.F, which has:

if(iopt_irr  >= 1) call read_mp_irrigation_parameters()

Therfore, as in my case, if you are not using irrigation iopt_irr=0, irrigation parameters are never read. Which might explain, why it does not have any value...?
So maybe, should the NOAHMP_INIT be modified, and introduce 'default' values to the irrigation_parameters values, to overcome the situation when irrigation is not used? Something like (I use the default values as they appear in read_mp_irrigation_parameters):

    ! Default values
    IRR_FRAC_TABLE   = -1.0E36    ! irrigation Fraction
    IRR_HAR_TABLE    =  0        ! number of days before harvest date to stop irrigation
    IRR_LAI_TABLE    = -1.0E36    ! Minimum lai to trigger irrigation
    IRR_MAD_TABLE    = -1.0E36    ! management allowable deficit (0-1)
    FILOSS_TABLE     = -1.0E36    ! fraction of flood irrigation loss (0-1)
    SPRIR_RATE_TABLE = -1.0E36    ! mm/h, sprinkler irrigation rate
    MICIR_RATE_TABLE = -1.0E36    ! mm/h, micro irrigation rate
    FIRTFAC_TABLE    = -1.0E36    ! flood application rate factor
    IR_RAIN_TABLE    = -1.0E36    ! maximum precipitation to stop irrigation trigger
    if(iopt_irr  >= 1) call read_mp_irrigation_parameters()

Although it would be more elegant if irrigation_parameters is called including the iopt_irr parameter and then inside:

(...)
  IF (iopt_irr >= 1) THEN
    inquire( file='MPTABLE.TBL', exist=file_named )
    if ( file_named ) then
      open(15, file="MPTABLE.TBL", status='old', form='formatted', action='read', iostat=ierr)
(...)
    read(15,noahmp_irrigation_parameters)
    close(15)
  END IF

And modify its call from NOAHMP_INIT as:

call read_mp_irrigation_parameters(iopt_irr)

 

[cenlinhe]

Thank you for diagnosing this and proposing the fix. I will try to fix this in a later version of WRF.

 

[tslin2]

Hi Lluís,
Just curious about the debug mode, what is the reason for running WRF v4.5.1 in debug mode. How do you run the debug mode? Did the WRF model crash without debug mode?

As I had seen in other forums, it seems not useful running in the debug mode (I mean the option in the namelist)

Thanks.

 

[ejanzon]

Not sure if this thread is still active, but before you went into debug mode with this problem, @LluisFB, were you encountering a seg fault when running with spectral nudging? I am having the same crash in module_sf_noahmplsm.f90, but it only happens when I have the coefficients set for spectral nudging.

​

 

[LluisFB]

Hi Lluís,
Just curious about the debug mode, what is the reason for running WRF v4.5.1 in debug mode. How do you run the debug mode? Did the WRF model crash without debug mode?

As I had seen in other forums, it seems not useful running in the debug mode (I mean the option in the namelist)

Thanks.

Hi @ejanzon, this is not using the debug mode inthe namelist, the debug is introduced during compilation. So, the model is running paying much more attention to some potential numerical hazards.
I would not say that debug mode in the namelist is useless. On the contrary, when one is facing this type of problems is very instructive

Lluís

 

[LluisFB]

Not sure if this thread is still active, but before you went into debug mode with this problem, @LluisFB, were you encountering a seg fault when running with spectral nudging? I am having the same crash in module_sf_noahmplsm.f90, but it only happens when I have the coefficients set for spectral nudging.

​

Hi, non I got the segfault only in debug mode.

I am running WRF in debug mode, because I found a segfault in the RRTMG module #post-39008. So I decided to understand what was going on, by compiling and running WRF in debug mode. In all this process I have been discovering other problems, like this one:

WRF debug error: cumulus kfeta

Dear all, I am running on a debug compiled version of WRF v4.5.1. I found an issue related to the Kain-Fritch cumulus scheme (mp_cumulus = 1). when running in debug mode I got the following error message: (...) forrtl: severe (408): fort: (3): Subscript #1 of the array THE0K has value 0 which...

forum.mmm.ucar.edu

WRF - debug: Floating point exception on p-level interpolation

Hi, On using a WRF v4.5.1 debug compiled version, I encounter the following Floating point exception error message: d01 2022-12-02_12:00:14 Input data is acceptable to use: [irene2433:1139612:0:1139612] Caught signal 8 (Floating point exception: floating-p oint divide by zero) ==== backtrace...

forum.mmm.ucar.edu

WRF debug: Floating point exception: Grell-Freitas (cu_scheme = 3)

Hi, running on a debug compiled WRF v4.5.1, I step into a floating point exception right at the beginning of the simulation with the Grell-Freitas cumulus scheme: (...) WRF NUMBER OF TILES = 1 [irene2054:3782323:0:3782323] Caught signal 8 (Floating point exception: floating-point invalid...

forum.mmm.ucar.edu

WRF debug mode, 'Subscript upper bound' error in Thompson microphysics

Hi, Running with a debug compiled WRF v4.5.1 version, I found an 'Subscript upper bound' error. The message I got is the following one: (...) WRF NUMBER OF TILES = 1 forrtl: severe (408): fort: (2): Subscript #3 of the array TMR_RACG has value 5 which is greater than the upper bound of 1...

forum.mmm.ucar.edu

debug compilation mode - Floating point exception in Boulac PBL scheme

Hi, Now it seems that in debug compilation mode, with WRF v4.5.1 (and the configuration I am using) model initializes properly. However, whilst integration, I step in a Floating point exception from the Boulac PBL scheme. The error message (after 333 seconds of integration, 10 time steps for...

forum.mmm.ucar.edu

Lluís