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

HFX, UST and GLW to zero with moving nests + high resolution topography

LisaMaillard

New member
Hello,

I am running WRF with 2 moving nested domains, with the high resolution topography option. However, some variables (at least HFX, UST, GLW) have strange values, being at 0 in d02 at all time steps, and at 0 in d01 in some random time steps. I tried the same configuration without the high resolution option, and the results are good.

For my moving nest + high resolution configuration, here are more information:
- I compiled WRF with the moving nest and --DTERRAIN_AND_LANDUSE options.
- I used USGS static data: geog_data_res = usgs_30s+default, usgs_30s+default, usgs_30s+default,
- I changed the num_land_cat to match the usgs : num_land_cat = 28.
- I indicated these lines in namelist.input:
input_from_hires = .false., .true.,.true.,
rsmas_data_path = "my_path_to_high_res_data"

Please find attached the namelist.input, namelist.wps and error log.

I am using WRF Model Version 4.2.1 and WRF Pre-Processing System Version 4.2

Do you have any guess on what is the issue ?
Thanks,
Lisa
 

Attachments

  • rsl.error.0000
    4.6 MB · Views: 2
  • namelist.input
    8.7 KB · Views: 5
  • namelist.wps
    1,019 bytes · Views: 3
Hi Lisa,
There have been a few modifications to the moving nest option since V4.2.1. Just as a test, can you try the latest version of WRF (V4.6.0) and see if that makes any difference? Thanks!
 
Hi Kelly, thanks for your answer.
I followed your advice and tried with WRF V4.6.0 and WPS V4.6.0, but it does not seem to make any difference unfortunately.
 
Hi Lisa,
I notice a few things in your namelist.input file that are odd, and I'm not sure if they are related to your issue. Your namelist.input file has the following settings:

Code:
num_land_cat = 28
num_metgrid_soil_levels = 0
max_cpldom = 1
input_from_hires  = .false., .true.,.true.,

1. Are you using another model to couple with WRF for this? I ask this because the variable "max_cpldom" does not exist in basic WRF.
2. You should have 4 soil levels from the input data (I assume you're using GFS?)
3. If you are using the settings given in your namelist.wps file (usgs_30s+default), then num_land_cat should be 24.
4. As for the 'input_from_hires' settings, I believe those should all be set to true - even domain 1. I'm not certain about that one, though.
 
Hi,
Thank you for your advice.

1. Indeed, the variable "max_cpldom" is used for coupling with an other model, but it is not activated in my case. I removed it to make sure it does not introduce errors.
2. You are right. I am using GDAS and I had an issue with my Vtable, which made ungrib not capable of finding soil temperature information and put 0 soil levels. It is resolved now and I have indicated 4 soil levels.
3. I was doing a symbolic link of landuse_30s to landuse_30s_with_lakes, as I did not have landuse_30s downloaded. That is why usgs_30s was in reality pointing at usgs_lakes (which has num_land_cat=28). It is resolved now and usgs_30s is pointing to the right folder and num_land_cat=24.
4. I tried setting input_from_hires = .true., .true.,.true.,

Please find attached the new namelist.input.

Unfortunately, all the above changes did not resolve the issue.
 

Attachments

  • namelist.input
    8.7 KB · Views: 1
Thanks for addressing those issues. I just want to let you know I haven't forgotten about you. I'm just having trouble getting this to even run at all on my end. I keep getting all kinds of errors, so this is taking me down a bunch of rabbit holes. I'm going to keep trying, though, until I can figure out something. Thank you for your patience!
 
Thanks a lot for your help, please let me know if you need other information about the simulation. I'll let you know if I find a solution on my side.
 
Hi Lisa,
Do you mind sharing your met_em.d01* files with me? I'd like to try to run this with your actual files. Those files will be too large to attach here, so see the home page of this forum for instructions on sharing large files.

Did you happen to verify whether this problem existed if running a vortex-following simulation without the high-res input? Just curious, as it may help to track down the issue.
 
Hi Kelly,

I have uploaded the met_em files on NextCloud (folder name: met_files_nested_simulation_gretel.tar.gz).

Without the high resolution input, the simulation is working without any problem.

I also tried running the simulation with WRFV3.7.1 and the high resolution input. It gives clean results without such problems.
 
Again, I'd like to reassure you that we are still working on this. I've been working with a colleague to try to identify the issue. We are able to repeat the problem, so that's a step in the right direction! Thank you for your continued patience.
 
Hi Lisa,
Just an update - we've been able to track down the code commit that caused this issue, but we haven't figured out why yet. We are still working on it. I apologize it's taking so long - we had to compile and test numerous commits to determine where the issue started happening. Hopefully I'll have an answer for you soon. Thank you so much for your patience.
 
Hi Kelly,
Thanks for the update and for all your hard work. It's great that you figured out which commit caused the issue. There is nothing urgent, I'll wait until you have more updates.
 
Top