Segmentation fault for idealized tropical cyclone simulation with a moving nest

[metjmartinez]

Hi,

I'm encountering a segmentation fault early in the integration of WRFv4.4 for an idealized simulation of a tropical cyclone. The simulation is configured with 2 nests and vortex tracking on the innermost nest. I compiled WRF with the debug flag and received the following error traceback:

forrtl: severe (174): SIGSEGV, segmentation fault occurred       
Image              PC                Routine            Line        Source
wrf.exe            0000000005B106AA  Unknown               Unknown  Unknown
libpthread-2.22.s  00002ABDD3795CE0  Unknown               Unknown  Unknown
wrf.exe            00000000052C57C6  module_sf_sfclayr        1329  module_sf_sfclayrev.f90
wrf.exe            00000000052BE5C3  module_sf_sfclayr         633  module_sf_sfclayrev.f90
wrf.exe            00000000052B9868  module_sf_sfclayr         253  module_sf_sfclayrev.f90
wrf.exe            0000000003DAA627  module_surface_dr        2033  module_surface_driver.f90
wrf.exe            000000000294D0DD  module_first_rk_s         428  module_first_rk_step_part1.f90
wrf.exe            00000000018DFFA1  solve_em_                1060  solve_em.f90
wrf.exe            00000000016B7258  solve_interface_          149  solve_interface.f90
wrf.exe            00000000005E3BEF  module_integrate_         365  module_integrate.f90
wrf.exe            00000000005E4206  module_integrate_         402  module_integrate.f90
wrf.exe            00000000005E4206  module_integrate_         402  module_integrate.f90
wrf.exe            000000000041D885  module_wrf_top_mp         354  module_wrf_top.f90
wrf.exe            000000000041CFA5  MAIN__                     55  wrf.f90     
wrf.exe            000000000041CF52  Unknown               Unknown  Unknown
libc-2.22.so       00002ABDD39C4AC5  __libc_start_main     Unknown  Unknown
wrf.exe            000000000041CE69  Unknown               Unknown  Unknown

There seems to be an issue with the allocation of the psim_stable variable within the subroutine SFCLAYREV1D from module_sf_sfclayrev.F. I discovered a post from the WRF User's forum archive where a user encountered the same issue: Segmentation Fault in "psim_stable" routine. I don't have a p_top value specified, but the variable "P_TOP" in the initial conditions file consistently produces ~23 hPa for my current configuration. Similar to the user in the linked post, I confirmed that the zolzz and zol00 variables are producing NaN values.

I attempted a few different configurations to see if I may have specified too many vertical levels or perhaps too high of a model top. I tried combinations of e_vert = 40, 50, or 60 and the model top ztop = 20000 or 25000. Each combination produced the same error traceback.

I also attempted modifying the dzstretch_s and dzstretch_u variables by setting both to 1.1 per one of the guidelines listed in the WRF Users Guide: WRF Initialization — WRF Users Guide documentation. Here, I tried one test with e_vert = 60 and got the same error traceback. I should note that dzstretch_s was 1.3 in the other tests I mentioned above.

Finally, I have verified that the -DMOVE_NESTS and -DVORTEX_CENTER options are listed in ARCHFLAGS in the configure.wrf file.

I'm likely overlooking something straightforward in my configuration. I'm attaching a tar file containing the rsl.error and rsl.out files, the namelist.input file, and input_sounding file for reference. The rsl.error.0000 file contains the relevant error traceback. Any help would be greatly appreciated!

Thanks,

Jon

 

[kwerner]

Hi Jon,
First, I would like to apologize for the long delay in response. I should have responded to at least let you know I've been looking at this and trying a few different things. I am also seeing the same issue as you. I'm trying a couple other tests, but I'm actually not even sure if it's possible to use the vortex-following option with an idealized case. I know others have had issues when trying to do it, and maybe that's why you're also experiencing this problem. I will let you know if I'm able to figure anything out that will be helpful to you, either way.

 

[weiwang]

Please try defining dampcoef in all three columns. This should allow nests running. Not sure why you need to use moving nests, as the idealized tropical storm case has no mean winds. If you do use vortex following, you should consider using corral_dist = 1, 8, 118 perhaps. This would keep domain 3 vortex in the center of domain 2, while domain 2 is allowed to move as close as 8 grid points near domain 1's boundary.

 

[metjmartinez]

Hi Kelly and Wei,

I apologize for the delayed response! Thanks for following up and looking into this problem. Prior to Wei's response, I had attempted to run the model with static nesting (nest=1) and was getting the same error traceback. As you noted Wei, the moving nest is not necessary given that the simulation is currently configured with no mean winds. However, I was planning to include mean winds and/or shear for a set of simulations, so I wanted to make sure that I could get the moving nest option working. Thanks for catching the issue with dampcoef and recommending a different configuration for corral_dist! I will make these updates to my namelist file.

I've been running tests over the last few weeks and was able to get the model running for ~15 minutes of simulation time without any issues for both the static and moving nest options. I think the original source of the problem may have been related to how I was requesting resources via a slurm job scheduler. Unfortunately, I'm not running my simulations on NCAR's supercomputers. I've submitted a longer job request with a 12-h walltime limit and will follow up here with the results from that test.