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

WRF V3.6.1 hang up

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

M

mawagner

New member
Hello,

I am running WRF V3.6.1 with Noah-MP with modifications to land cover (wrfinp files), time varying vegetation parameters (LAI, ALBBCK, VEGFRA in wrflow files), and changes to VEGPARM.TBL and MPTABLE.TBL. I am using 112 cores across 4 nodes with openmpi/1.8.4-intel-2015.2. My model hangs up at the same time step and spot:

d01 2015-02-23_05:00:00 calling inc/HALO_EM_HELICITY_inline.inc
d01 2015-02-23_05:00:00 calling inc/HALO_EM_TKE_D_inline.inc
d01 2015-02-23_05:00:00 call calculate_km_kh
d01 2015-02-23_05:00:00 calling inc/HALO_EM_TKE_E_inline.inc

I reduced the time step from 60 to 20 and increased the frequency of restart files, but the model still hangs up. I had similar issues with my control simulation, but was able to overcome the model hanging by setting w_damping =1, damp_opt=3, radt = 15, 15. Unfortunately, setting these options and reducing the time step is not working. Additionally, I have looked at the met-em files: all the data values look realistic. Do I have an incompatible setting? How can I overcome model instability to get my model working?

Thanks and Best
 

Attachments

  • namelist.input
    5.1 KB · Views: 57
  • MPTABLE.TBL
    32.8 KB · Views: 54
  • VEGPARM.TBL
    22.1 KB · Views: 51
I am sorry I don't have an immediate solution to your problem. Your namelist.input looks fine and I don't see any inappropriate settings.
Since your case is a long-term climate run, I wonder whether it is practical that you stay with the default options of noahMP and see how it works.
The model hang up can be attributed to various factors, and you need to check where it stops and look at all related variables.
 
Hello Ming,

Could you please provide a more detailed response as to which various factors I should check? It is stopping here: calling inc/HALO_EM_TKE_E_inline.inc. How do I trace which variables are related? The model ran fine (for the most part including the Noah-NP default settings) without changing wrfinp and wrflow files. I would really appreciate help on getting my model to continue to run.

Thanks and Best,
Melissa
 
Melissa,
When you run with higher debug levels, you got the message like: "calling inc/HALO_EM_TKE_E_inline.inc.". However, this kind of message doesn't really help to debug the problem.
What I usually do is to first check all rsl files, and one or a few of them may include the error message that is helpful for debugging. I also save wrfout at every time step right before the model crash (e.g., you can save wrfrst 30 minutes before the model crash, then restart and save wrfout every time step). Then we can look at these wrfout files. If the physics is wrong, we may find NaN values for some variables in wrfout. From there, we can further track the reasons for model crash.
We also consult our NoahMP experts, hoping to get some information why some cases/options don't work. Unfortunately they are very busy and seldom get back to us. NoahMP involves so many variables and input data, any of them can lead to problems in model running. It is hard for me to tell which options or variables cause the model to crash, unless I can repeat your case and debug it.
 
Hello Ming,

Thanks for your reply. That information helped. It appears that my issue is with LAI values. I overwrote LAI, ALBBCK, and VEGFRA in the wrflows files for a land cover class. When DVEG = 1: ALBBCK and VEGFRA look fine in the model output, but LAI values go to zero in the wrfoutput files as the model continues to run. I am trying to figure out what process is overwriting the LAI values in the wrflow files that I would like to use. I am running a simulation with DVEG = 4 to see if that does the trick. Do you have any other suggestions to try or look into?

Thanks and Best,
Melissa
 
Melissa,
if you look at the code phys/module_sf_noahmplsm.F, you will find that LAI is updated depending on the namelist options. We did find that in Noah, when vegetation fraction is small, LAI value can be zero, which leads to model crash. The same might happen in NoahMP. Please check when and where LAI goes to zero, and try to figure out what variables lead to zero LAI.
 
Hello Ming,

Thanks for your insight. I am going to dig deeper into the LAI values and module_sf_noahmplsm.F as you have suggested. I am seeing better results when I use DVEG = 4, but it still crashes. I need to double check and make certain there are not any zero LAI values when veg frac values are small.

When I use Noah-LSM with modifications, the model runs successfully. In the run I am conducting now (Noah-MP), I modified ALBBCK and VEGFRA, but only changed LAI monthly values in the MPTABLE.TBL instead of the wrflowinp files like I had been doing. So I will see how that goes. The issue could be related to an incompatible parameter I changed in the MPTABLE.TBL? I will let you know if I was able to locate the issue.

Thanks and Best,
Melissa
 
Hello Ming,

I was able to locate my issue. In the MPTABLE.TBL, I had changed the XL parameter to -0.40 based on the same value in the CLM model for this specific land cover class and literature. When I change the value to -0.30, the model runs successfully.

Best,
Melissa
 
You must log in or register to reply here.
Top