Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault with sf_surface_mosaic in WRF4.3.1. #1633

Closed
epn09 opened this issue Jan 11, 2022 · 2 comments · Fixed by #1638
Closed

Segfault with sf_surface_mosaic in WRF4.3.1. #1633

epn09 opened this issue Jan 11, 2022 · 2 comments · Fixed by #1638
Assignees

Comments

@epn09
Copy link
Contributor

epn09 commented Jan 11, 2022

Describe the bug

  • Error when using sf_surface_mosaic = 1.
  • There is no error if sf_surface_mosaic = 0.

To Reproduce
Steps to reproduce the behavior:

  1. Use compiler and version: ifort version 2021.3.0
  2. Use namelist options
 sf_surface_physics = 2 2 ,
 sf_surface_mosaic = 1,
  1. Output is '....'
forrtl: severe (408): fort: (2): Subscript #1 of the array ZR_TBL has value 5 which is greater than the upper bound of 3

Image              PC                Routine            Line        Source
wrf.exe            000000000CEB4CEF  Unknown               Unknown  Unknown
wrf.exe            000000000494070F  module_sf_urban_m        1875  module_sf_urban.f90
wrf.exe            000000000492E47E  module_sf_urban_m         607  module_sf_urban.f90
wrf.exe            000000000BAEC8B5  module_sf_noahdrv        3653  module_sf_noahdrv.f90
wrf.exe            000000000855B5CD  module_surface_dr        2477  module_surface_driver.f90
wrf.exe            00000000051BE069  module_first_rk_s         380  module_first_rk_step_part1.f90
wrf.exe            000000000401F69C  solve_em_                 883  solve_em.f90
wrf.exe            0000000003906047  solve_interface_          122  solve_interface.f90
wrf.exe            00000000005B447E  module_integrate_         329  module_integrate.f90
wrf.exe            0000000000414478  module_wrf_top_mp         326  module_wrf_top.f90
wrf.exe            00000000004138A5  MAIN__                     29  wrf.f90
wrf.exe            0000000000413852  Unknown               Unknown  Unknown
libc-2.26.so       000014D71E3E234A  __libc_start_main     Unknown  Unknown
wrf.exe            000000000041376A  Unknown               Unknown  Unknown

Expected behavior

  • There should be no error.

Attachments

Additional context
I think the error is due to #1419, particularly this change:

  • Before (line 3604):

    WRF/phys/module_sf_noahdrv.F

    Lines 3601 to 3607 in 236c1de

    ! UTYPE_URB = UTYPE_URB2D(I,J) !urban type (low, high or industrial)
    ! this need to be changed in the mosaic danli
    IF(IVGTYP(I,J)==ISURBAN) UTYPE_URB=2
    IF(IVGTYP(I,J)==LOW_DENSITY_RESIDENTIAL) UTYPE_URB=1
    IF(IVGTYP(I,J)==HIGH_DENSITY_RESIDENTIAL) UTYPE_URB=2
    IF(IVGTYP(I,J)==HIGH_INTENSITY_INDUSTRIAL) UTYPE_URB=3
  • After (line 3632):

    WRF/phys/module_sf_noahdrv.F

    Lines 3624 to 3634 in c2f9b99

    IF( IVGTYP(I,J) == ISURBAN .or. IVGTYP(I,J) == LCZ_1 .or. IVGTYP(I,J) == LCZ_2 .or. &
    IVGTYP(I,J) == LCZ_3 .or. IVGTYP(I,J) == LCZ_4 .or. IVGTYP(I,J) == LCZ_5 .or. &
    IVGTYP(I,J) == LCZ_6 .or. IVGTYP(I,J) == LCZ_7 .or. IVGTYP(I,J) == LCZ_8 .or. &
    IVGTYP(I,J) == LCZ_9 .or. IVGTYP(I,J) == LCZ_10 .or. IVGTYP(I,J) == LCZ_11 ) THEN
    ! UTYPE_URB = UTYPE_URB2D(I,J) !urban type (low, high or industrial)
    ! this need to be changed in the mosaic danli
    IF(IVGTYP(I,J)==ISURBAN) UTYPE_URB=5
    IF(IVGTYP(I,J)==LCZ_1) UTYPE_URB=1
    IF(IVGTYP(I,J)==LCZ_2) UTYPE_URB=2
@weiwangncar
Copy link
Collaborator

@epn09 Do you have a simple fix for this? If you do, can you test it and let us know?

@epn09
Copy link
Contributor Author

epn09 commented Jan 12, 2022

@weiwangncar Please take a look at #1638.

davegill pushed a commit that referenced this issue Jan 19, 2022
…z = 0 (#1638)

TYPE: bug fix

KEYWORDS: noah mosaic, wudapt

SOURCE: Do Ngoc Khanh (Tokyo Institute of Technology)

DESCRIPTION OF CHANGES:
Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0.

Problem:
Segmentation fault occurs when running the model using sf_surface_mosaic = 1 with use_wudapt_lcz = 0 as described in detail in #1633. 

Solution:
The code now checks for use_wudapt_lcz and uses different code to define urban categories in lsm_mosaic routine in module_sf_noahdrv.F.

ISSUE: 
Fixes #1633 

LIST OF MODIFIED FILES:
M       dyn_em/module_first_rk_step_part1.F
M       phys/module_sf_noahdrv.F
M       phys/module_surface_driver.F

TESTS CONDUCTED: 
1. When use_wudapt_lcz = 1: bit-by-bit identical output before and after modification.
2. When use_wudapt_lcz = 0: Segmentation fault is fixed.
3. The Jenkins tests are all passing.

RELEASE NOTE: Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0.
@epn09 epn09 closed this as completed Jan 20, 2022
vlakshmanan-scala pushed a commit to scala-computing/WRF that referenced this issue Apr 4, 2024
…z = 0 (wrf-model#1638)

TYPE: bug fix

KEYWORDS: noah mosaic, wudapt

SOURCE: Do Ngoc Khanh (Tokyo Institute of Technology)

DESCRIPTION OF CHANGES:
Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0.

Problem:
Segmentation fault occurs when running the model using sf_surface_mosaic = 1 with use_wudapt_lcz = 0 as described in detail in wrf-model#1633. 

Solution:
The code now checks for use_wudapt_lcz and uses different code to define urban categories in lsm_mosaic routine in module_sf_noahdrv.F.

ISSUE: 
Fixes wrf-model#1633 

LIST OF MODIFIED FILES:
M       dyn_em/module_first_rk_step_part1.F
M       phys/module_sf_noahdrv.F
M       phys/module_surface_driver.F

TESTS CONDUCTED: 
1. When use_wudapt_lcz = 1: bit-by-bit identical output before and after modification.
2. When use_wudapt_lcz = 0: Segmentation fault is fixed.
3. The Jenkins tests are all passing.

RELEASE NOTE: Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants