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

SLUCM : segmentation Error.

Dipson11

Member
Hi,

I am facing segmentation error while using SLUCM . In run for a day and stop with this error. I am tried multiple option like "ulimit -s unlimited" and changing the physics option but nothing worked out.Since my domain is in high terrain region I have set the parameters accordingly following different sources in the forum. I have attached all the necessary files. I would really appreciate your feedback.
Thank you very much
 

Attachments

  • namelist.input
    4.8 KB · Views: 7
  • rsl_error.txt
    46.1 KB · Views: 3
  • rsl_out.txt
    43.8 KB · Views: 2
Hi,
Your namelist.input looks fine to me. However, there is no concrete error message in your rsl files that are helpful. Please check all the rsl files for this case, and find critical error messages that can help us to figure out what is wrong. Note that the error message can be in any rsl files.
 
By the way, if you run this case over a single domain, can it run to the end successfully?
Hi chen, thank you for your reply. It runs over a single domain and also runs when urban physics is turned off. It crashes after few days while tunning UCM with LCZ activated. I found few solutions in forum like turning one parameter from 1 to 2 in Urbparm_LCZ.tbl but it didnot work . I am using WRFV4.5.2 . I found your comment in one of the forums post whete you suggested to use WRFV4.3.3. But it still crashes. UCM is crashing over most the versions that I tried. Would you recommend any version? I am currently compiling WRFV4.6 to check if it works there.
 
By the way, if you run this case over a single domain, can it run to the end successfully?
Forrrl severe 174 sigsegv segmentation error occurred. I am using mpi run -np36 and tried with both high number and low number processors
 
I changed TS_SCHEME in URBPARM_LCZ.tbl from 1 to 2 , but it has same problem. "forrtl: severe (174): SIGSEGV, segmentation fault occurred"
 
Thanks for the update.
Segmentation fault is often attributed to either memory issue or physics problem. In your case, the model crashed after a while, which indicates that something might be wrong in the physics.
I would suggest that you recompile WRF in debug mode ( i.e., ./clean -a, then ./configure -D), and rerun this case. You should be able to find exactly when and where the model crashes, which gives you some hints what is wrong.
LCZ is a relatively new feature and there might have some hidden problems we don't know yet.
 
Hello,

I am facing the same error where using wrf 4.6 with lcz on a supercomputer (so I assume it is not a memory issue) it immediately crashes with no helpful rsl error but 174. It runs fine without using LCZ. The only changes I had were setting use_wudapt_lcz =1, linking GEOGRID.TBL_LCZ with GEOGRID.TBL, and defining lcz data in namelist.input. I am also using SLUM.

Do you have any guidance on what could be the problem or work around? I will also try it with debug mode

should I change URBPARM_LCZ.tbl or that wont help?
 
Hello,

I am facing the same error where using wrf 4.6 with lcz on a supercomputer (so I assume it is not a memory issue) it immediately crashes with no helpful rsl error but 174. It runs fine without using LCZ. The only changes I had were setting use_wudapt_lcz =1, linking GEOGRID.TBL_LCZ with GEOGRID.TBL, and defining lcz data in namelist.input. I am also using SLUM.

Do you have any guidance on what could be the problem or work around? I will also try it with debug mode

should I change URBPARM_LCZ.tbl or that wont help?
Hi,

Unfortunately, I could not find a solution to this issue . I run it on a supercomputer too, but the problem persists. In my case, I wanted to run 30days simulation but, I could run it for 10days . It didn't crash immediately like in your case . So, like chen said , the problem might be with LCZ feature in WRF.

While solving this problem, I came across one similar issues in the forum where the user had solved it by changing TS_SCHEME in URBPARM_LCZ.tbl from 1 to 2. It didn't work for me, but you can try . As, in your case it immediately crashes , the problem could be with the domain configuration , Physics option , Number of processor that you are using . My case had innermost nested domain resolution of 1.6 km .
I checked it on different versions like v4.3.3 , v4.5 , v4.6 , Let me know if you find any solutions to this problem , I spent some good amount of days working with this problem.
 
Hi,

Unfortunately, I could not find a solution to this issue . I run it on a supercomputer too, but the problem persists. In my case, I wanted to run 30days simulation but, I could run it for 10days . It didn't crash immediately like in your case . So, like chen said , the problem might be with LCZ feature in WRF.

While solving this problem, I came across one similar issues in the forum where the user had solved it by changing TS_SCHEME in URBPARM_LCZ.tbl from 1 to 2. It didn't work for me, but you can try . As, in your case it immediately crashes , the problem could be with the domain configuration , Physics option , Number of processor that you are using . My case had innermost nested domain resolution of 1.6 km .
I checked it on different versions like v4.3.3 , v4.5 , v4.6 , Let me know if you find any solutions to this problem , I spent some good amount of days working with this problem.
Thank you for these suggestions, I will try to implement them and my simulation is only 4 days so I hope it will not take long. I still have not found a solution. However, when I looked at geogrid.log I saw this warning for each variable:
INFORM: For HGT_M, couldn't find interpolator sequence for resolution cglc_modis_lcz.
(and the same for LANDUSEF etc)
I am wondering if you have it? I do not think the geogrid is reading the LCZ data at all in this case. Although for some reason the first time I ran LCZ I did not face this issue I believe.
 
Thank you for these suggestions, I will try to implement them and my simulation is only 4 days so I hope it will not take long. I still have not found a solution. However, when I looked at geogrid.log I saw this warning for each variable:

(and the same for LANDUSEF etc)
I am wondering if you have it? I do not think the geogrid is reading the LCZ data at all in this case. Although for some reason the first time I ran LCZ I did not face this issue I believe.
can you share your namelist.wps and namelist.input file, I can check it when I am free.
 
Yes I am tried with default and I get the same issue, and I was using these because it was recommended for SLURM
What variables are you trying to analyze from this simulation ? I use normal "cglc_modis_lcz +default" for all the domain ,

for example :
geog_data_res = 'cglc_modis_lcz+default','cglc_modis_lcz+default','cglc_modis_lcz+default',


It should work, you are complicating the geo_data_res, in my opinion , as cglc_modis_lcz , itself represent the data for 2018. So, try the setting mentioned above once.

Meanwhile, refer to this article for better understanding of cglc_modis_lcz ,

 
What variables are you trying to analyze from this simulation ? I use normal "cglc_modis_lcz +default" for all the domain ,

for example :
geog_data_res = 'cglc_modis_lcz+default','cglc_modis_lcz+default','cglc_modis_lcz+default',


It should work, you are complicating the geo_data_res, in my opinion , as cglc_modis_lcz , itself represent the data for 2018. So, try the setting mentioned above once.

Meanwhile, refer to this article for better understanding of cglc_modis_lcz ,

I see, but lcz data should take priority in any case, I did run it with default and I still get this in the geogrid.log file for all the variables in GEOGRID.TBL and the geogrid resulting has 21 categories instead of 61

INFORM: For LANDUSEF, couldn't find interpolator sequence for resolution cglc_modis_lcz.
INFORM: Using default interpolator sequence for LANDUSEF.
INFORM: For LANDUSEF, couldn't find cglc_modis_lcz data source.
INFORM: Using default data source for LANDUSEF.
 
I see, but lcz data should take priority in any case, I did run it with default and I still get this in the geogrid.log file for all the variables in GEOGRID.TBL and the geogrid resulting has 21 categories instead of 61
I was able to fix it!

The GEOGRID.RBL was not linked properly but now it worked and I was able to run WRF with changing WPS_GEOG/CGLC_MODIS_LCZ_global/index
values to this:

tile_x=400752
tile_y=153622
 
Top