./wrf.exe error: bucket_mm=100 and bucket_J=1.e9 (SIGSEGV: Segmentation fault)

[lslrsgis]

Dear WRF community,

When adding bucket_mm=100 and bucket_J=1.e9 to namelist.input, ./wrf.exe would give an error for the first file as follows:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

When I change these two lines to: bucket_mm=-1 and bucket_J=-1, ./wrf.exe works successfully.

Is there anything more to pay attention in namelist.input? Wrf.log and namelist.input are attached. Thanks.

 

[kwerner]

Hi,
This may be related to a problem we have seen prior to this, regarding memory allocation. We haven’t quite figured out the root of it, but I have a solution for you to bypass the problem for now (hopefully). I'm attaching a modified Registry.EM_COMMON file for v4.0. The changes I made are to remove all the packaged parameters associated with some of the bucket terms. So the original lines were:

package   prec_acc       prec_acc_opt==1            -              state:prec_acc_c,prec_acc_nc,snow_acc_nc
package   bucketropt     bucketr_opt==1             -              state:i_rainc,i_rainnc
package   bucketfopt     bucketf_opt==1             -              state:i_acswupt,i_acswuptc,i_acswdnt,i_acswdntc,i_acswupb,i_acswupbc,i_acswdnb,i_acswdnbc,i_aclwupt,i_aclwuptc,i_aclwdnt,i_aclwdntc,i_aclwupb,i_aclwupbc,i_aclwdnb,i_aclwdnbc

and now they are:

package   prec_acc       prec_acc_opt==1            -              -
package   bucketropt     bucketr_opt==1             -              -
package   bucketfopt     bucketf_opt==1             -              -

You will need to place this new file in your WRF/Registry/ directory. After that, because you’re changing the registry, you’ll need to go back to WRF/ and issue a ‘clean -a’ and then reconfigure and recompile. Then run to see if this allows you to overcome the stop. If so, the only problem with the ‘fix’ is that you will now get a bunch of new variables that you likely don’t want. It won’t make the runtime longer, but will make the files larger. Since you’re running for several years, this may not be ideal (but since you are outputting files often, it may be okay for you). If not, then I would suggest taking a look at one of your look at your original wrfout* file (from the failed run) somewhere. It likely will have all the variables listed in it, so if you use something like ncview, you can check to see what variables are created. Then run another very short run with the fix, and use ncview to look at those variables. For all the extras listed, you can use our Runtime I/O option to simply remove them from your history files. You can read about that option here:
http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3.9/users_guide_chap5.htm#runtimeio

Let me know if this revised Registry.EM_COMMON file helps your problem.

Kelly

 

[lslrsgis]

Thanks. Sorry for the late reply.

I have followed your advise to replace Registry.EM_COMMON, then ./clean -a, and recompiled wrf.exe. Corresponding, bucket_mm=100 and bucket_J=1.e9 are set in namelist.input.

However, there is a runtime error when ./wrf.exe with new configuration. The program stopped at the beginning. log files for this fail are attached.

 

[kwerner]

Hi,

Can you first check to make sure that you have enough disk space in the directory where you are trying to run this, and that you have permission to write to that directory?

If that's not the problem, can you attach the following:
1) your new namelist.input file
2) your modified Registry.EM_COMMON file
3) the first 2 time periods of your met_em* files for both domains (so I should have 4 files). Package these into 1 *.tar file. If you have trouble attaching them because of size, and you don't have another method you can send them through a downloadable link, please see the home page for this forum for instructions on sending large files.

Thanks,
Kelly

 

[lslrsgis]

Thanks. I have attached the four files with namelist.output. The Registry.EM_COMMON is exactly the same as you attached.

I confirm the permission to write in this folder since default simulation (without registry modification and bucket options) has generated output files.

 

[kwerner]

I am able to run that with V4.0, your namelist and your met_em* files without any problem; however, you only sent the met_em* files for d01, and it looks like your run is stopping on d02. Can you send the 2 met_em* files for d02, as well, so that I can try both domains?

Thanks,
Kelly

 

[lslrsgis]

Thanks Kelly. I have forget to attach met_em.d02*.

 

[kwerner]

Thanks for sending those. I realized that yesterday when I tested d01, I was using 36 processors, and you are only using 1, so when I tested both domains today, I tried with only 1 processor. Again, I was using V4.0, your namelist.input file and your met_em.d0* files, and the run completes without any problems. I am doing this test with an Intel processor. What type/version processor are you using? Can you attach your configure.wrf file?

 

[lslrsgis]

Thanks Kelly. In this experiment, I am using GNU+smpar+basic nesting options. configure.wrf is attached.

 

[kwerner]

Thanks. I tried this again with a GNU/smpar build and I'm still not having any problem running it. At this point, it seems to be a problem that is specific to your environment. I would suggest discussing the issue with your systems administrator at your institution to see if they can help to figure out what is going on.

Kelly