WRF4.2.1_Segmentation fault (FSBM-2, mp_physics=30)

Hello,
I tried to rebuild the MC3E case at May 19, 2011 by using FSBM-2(mp_physics=30) in WRF-4.2.1.(Shpund et al. 2019)
The NCEP-FNL 1*1 degree analyses were used as the initial and boundary condition.
However, the "Segmentation fault (core dumped) ./real.exe" I got, while I was running real.exe.
The problem is solved by changing the mp_physics form 30(FSBM-2) to another scheme (mp_physics = 6), and then I got the wrfinput and wrfbdy successfully.
The error messages for real.exe: View attachment rsl.error.0000.txt
The another mp_scheme(e.g. GCE4ice, WDM7) can run wrf.exe for several time steps(in namelist.input, time_step = 15), but still FSBM-2 got "Segmentation fault" in the first time step.
The error messages for wrf.exe: View attachment rsl.error.0000_forwrf.txt
I'm not sure I get the picture to the problem. I think it may be the NCEP-FNL analysis in 2011 is incompatible with WRF-4.2.1. I was wondering if someone could give me some advice about this problem. Thanks a lot.

View attachment namelist.wps

successive run WRF with mp_physics=6, but mp_physics=30 return seg. fault.
View attachment namelist.input


best regards,

Hi,
NCEP-FNL should be compatible with V4.2.1, so I don't think that is the problem. Can you test this with an older version of WRF (maybe v4.0) and let me know if you have the problem there? Thanks!

The WRFv4.0 also got the "Segmentation fault (core dumped) ./real.exe" when I set "mp_physics = 30" in namelist.input.
Also, "mp_physics = 6" worked and then I got the wrfinput and wrfbdy successfully. The rsl.error.0000 below:
View attachment seg_fault_rsl.error.0000.for_mp_phy30.txt
View attachment succcess_rsl.error.0000.for_mp_phy6.txt

By the way, the WPS version is 4.0 here. (I used WPSv4.2 in previous test of WRFv4.2.1.)

The another case in 2019 I tested for mp_physics = 30 doesn't have this problem. That's the reason why I think may be the incompatible problems with "mp_physics = 30" or something else. And note that mp_physics = 30 in WRFv4.0 is old version (FSBM-1), and new version (FSBM-2) is updated at WRFv4.2. Both version of FSBM couldn't run real.exe in my tests.
If you need more detail information, I will give you as soon as possible. Thanks !

Hi,
When you ran the successful 2019 case with mp_physics=30, was your set-up identical (same domain sizes, resolution, area, same physics options, etc.). I.e., did you ONLY change the case date, or are there other differences between the successful case and the newer failed case with mp_physics=30?

Hi,
The WPS settings of the successful 2019 case, which is over East Asia, is totally different from 2011 MC3E case in U.S. I followed your suggestion to change the date to Dec. 5, 2019 and my set-up is identical with 2011 MC3E case in WRFv4.0. I found that "real.exe" also got Segmentation fault with mp_physics=30 and succeed with mp_physics=6. I think the problem may be led by the settings of domain, and the previous question for NCEP-FNL has been excluded.

Thanks for checking on that. Can you send a couple of your met_em* files for each domain so that I can test this? If the files are too large to attach, take a look at the forum home page to see instructions for uploading large files. Thanks!

The associated files have been compressed and uploaded to Nextcloud .
mp30_seg_fault.tar.gz

Thanks a lot!

Thanks for sending those! I believe the problem may be that you are only using a single processor to run real.exe when you are using the SBM scheme. It may be that because this scheme requires the extra table files (scattering_tables_2layer_high_quad_1dT_1%fw_110) and input files (SBM_input_33), and perhaps this particular domain set-up and date/time sequence is requiring more processors. I also got a segmentation fault when I tried to only run with 18 processors. I then increased the number and was able to complete real.exe without errors (using your namelist.input, your met_em* files, and WRFV4.2.1).

Note: I set debug_level = 0 in the namelist. This isn't very useful and often ends up making the files much larger than necessary. I also had to change num_metgrid_levels to 34 (you had 32 in the namelist) to match the number of levels in your met_em* files.