Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

DZ8W, ZLVL become NaN value with sf_sfclay_physics=1(MM5), sf_surface_physics=4(NOAH MP)

syyang

New member
Hello,

I'm running a model with WRF version 4.5.2, but it can't proceed any further due to an error.

What is unusual is that if I set the domain to nesting d02, it runs normally, but if I set it to d01, the model does not run.

Also, even when set to one domain, it performs well if I change the surface and pbl schemes.
error : bl_pbl_physics - (1) YSU scheme, sf_sfclay_physics - (1) Revised MM5 Monin-Obukhov scheme (Jimenez, renamed in v3.6)
success : bl_pbl_physics - (2) Mellor-Yamada-Janjic TKE scheme, sf_sfclay_physics - (2) Monin-Obukhov (Janjic) scheme


I tried tracking WRF.exe trace and found that the error occurs in module_sf_noahmplsm.f90.
>>> addr2line -f -e ./wrf.exe 0x1d5ba80

module_sf_noahmplsm_bare_flux_
/shared/1.WRF_v4.5.2/WRFV4.5.2/phys/module_sf_noahmplsm.f90:4374

So when I output the actual values in phys/module_sf_noahmplsmdrv.F and phys/module_surface_driver.F, the second time step (after 15 seconds) ZLVL became nan, and before that, DZ8W became nan.
The DZ8W calculated in start_date is a normal value without nan values, but after the second time step of 15 seconds, it contains nan values.

Here, DZ8W seems to be an INput value that divides the vertical layer, but I don't know why this value becomes NAN.

It is also questionable that changing sf_sfclay_physics performs normally without nan values.

Please help me.
 

Attachments

  • namelist.input
    3.7 KB · Views: 1
I traced the ZLVL, DZ8W variables:

ZLVL is an input to NOAHMP_SFLX. When NOAHMP_SFLX is called, the variable is named Z_ML. Z_ML is assigned earlier:
Z_ML = 0.5*DZ8W(I,1,J) ! DZ8W: thickness of full levels; ZLVL forcing height [m]

DZ8W is an input to noahmplsm subroutine:
REAL, DIMENSION( ims:ime, kms:kme, jms:jme ), INTENT(IN ) :: DZ8W ! thickness of atmo layers [m]

Which itself is an input to the surface_driver subroutine:
REAL, DIMENSION( ims:ime, kms:kme, jms:jme ), INTENT(IN ):: DZ8W

Which is called from first_rk_step_part1. In that subroutine, it is filled during the call to phy_prep where it is set as follows:
dz8w(i,k,j) = z_at_w(i,k+1,j)-z_at_w(i,k,j)

Also note that phy_prep is called from an OMP loop.

Finally the variable is declared in i1_decl.inc:
real ,DIMENSION(grid%sm31:grid%em31,grid%sm32:grid%em32,grid%sm33:grid%em33) :: dz8w

Can we find the cause of the NaN value of DZ8W in this situation?
 
Top