(RESOLVED) Problems with different resolution Mandatory Static Data

[svangorder]

Hi

I'm having a problem with geogrid processing of the high resolution Mandatory Static Data (geog_high_res_mandatory.tar.gz) which I downloaded from http://www2.mmm.ucar.edu/wrf/users/download/get_sources_wps_geog.html#mandatory.

My nominal grid resolution is 5km over the area 103W - 71.4W and 13N - 37N so 2min data should be adequate for interpolation to my grid. For most fields, only the default resolution is included in the data set and it is the highest resolution described in GEOGRID.TBL.ARW; typically 30sec. But for two fields, VAR_SSO and LAI12M, the default resolution is 10min even though higher resolutions are provided. The LAI12M 10min and 30sec look quite similar, but the different resolution VAR_SSO data are vastly different. Their magnitude varies by more than an order of magnitude. Here is a table and there are plots below. Note the different scaling in each plot.

10m resolution range: 0 - 547160 , mean: 6950
2m resolution range: 0 - 298270 , mean: 1555
30s resolution range: 0 - 40212 , mean: 306

Does anyone know why the different VAR_SSO data should be so different? I'm very confused about which resolution data to choose. I'm new to WRF and its many inputs so I don't have a good feel for what are reasonable values of VAR_SSO. I'm uncomfortable with blindly using the default data.

Any insights would be greatly appreciated,

Steve

 

[kwerner]

Hi Steve,
I first would like to apologize for the long delay in response. It seems as though this post was overlooked. I'm sorry for the inconvenience.

Have you been able to get past the problem since this was originally posted? If not, can you let me know which version of WPS you are using? Can you also please attach your namelist.wps file, along with your GEOGRID.TBL?

Thanks,
Kelly

 

[svangorder]

Hi Kelly,

Thanks for finding this ... It was a pleasure to meet you at the February COAWST Workshop! You all were so very helpfull.

No I haven't sorted this out yet. I had left it alone and moved on with the rest of the WPS processing using all default geogrid data - figuring that someone would eventually respond and I could go back and fix things if need be. For future reference, whats the best way to prod you guys if something is missed?

I'm running WRF 4.0.3 and WPS 4.0.2 as distributed with COAWST 3.4

I used a slightly modified version of GEOGRID.TBL.ARW to allow me to use 2m resolution VAR_SSO without also getting 2m resolution SOILCTOP and SOILCBOT. Both files are attached.

I used 3 different namelist.wps as below with my GEOGRID.TBL.SVG.ARW.

namelist.v0.wps, geog_data_res = 'default'
use all default resolution selections

namelist.v1.wps, geog_data_res = 'modis_lai+30s+default'
use 30s resolution LAI12M data rather than default 10m resolution data
and 30s resolution VAR_SSO data rather than default 10m resolution data

namelist.v2.wps, geog_data_res = 'modis_lai+2m+default'
use 30s resolution LAI12M data rather than default 10m resolution data
and 2m resolution VAR_SSO data rather than default 10m resolution data

Best,
Steve

 

[kwerner]

Hi Steve,

Thank you! We enjoyed getting to work with you guys in NC.

I have to admit I don't know a lot about the VAR_SSO data, and the person who would know a bit more isn't in the office today. Upon researching this, it looks like beginning with V3.6 of the WRF model, lower-resolution VAR_SSO data was introduced because "it's more appropriate for lower-resolution runs." Without any additional information, I'm not sure what the threshold is for a "lower-resolution" run in that sentence, but as it's been made the default, I have to assume that the majority of simulations would fall into that category. Because you are running a 5km resolution domain, however, with is fairly high resolution, I would assume that using the 2m data would likely be the most appropriate for you.

As for the difference between the datasets, with resolution difference, I think this is simply just because of the resolution, itself. When I look at the 10m LAI data, vs. the 30s LAI data, I am actually seeing a pretty significant difference, as well.

I will run this question by my colleague to see if they have any more in-depth information that could be useful to you, and will get back to you.

Kelly

 

[svangorder]

Hi Kelly,

Is there any progress on this issue?

Thanks,
Steve

 

[kwerner]

Steve,
Again I apologize for the delay. I have been trying to track down a reasonable explanation regarding why a 10 arc-minute dataset was chosen as the default. It seems that perhaps we chose that because most users are not planning to use the topo_wind option when running WRF, and if these data are included in the standard static dataset, then trying to process geogrid with a large domain and coarser resolution would be very slow. This idea, however, is now being debated as to whether this is the correct approach, so hopefully a conclusion will be made about the future of these data with the code.

In general, though, the resolution of VARSSO should have a similar resolution to the elevation resolution that will be used (it is supposed to only be unresolved variance). If you do not have any plans to use the topo_wind option (which is a topographic correction for surface winds to represent extra drag from sub-grid topography and enhanced flow at hill tops - only works with the YSU PBL scheme), then this shouldn't be an issue for you, and it would be safe to use the default.

Kelly

 

[svangorder]

Hi Kelly,

Thank you for this reply! The way you described the VAR_SSO data made me finally realize why its magnitude increases by orders of magnitude with decreasing resolution. Since it is the unresolved sub-grid variance, it is highly resolution dependent. All along, I was thinking in terms of a physical variable like SST that would just look smoother with decreasing resolution.

I now realize that VAR_SSO is a variable for which it is important to match the resolution of the data to the resolution of the model topography - as you say. Defaulting the data to the highest resolution seems a safe thing to do in most cases (e.g. SST and LAI) but for a variable that is highly scale-dependent like VAR_SSO, its doubtful that there is a "safe" default for all users.

At this point, I haven't decided on the PBL, but YSU was one I was considering. I was just reading the documentation where it says that topo_wind "requires extra input from geogrid" and was wondering what that might be when ... I got your reply!

If I do use YSU with topo_wind, it seems to me that the 2min (~3.7Km) data would be the best match for my 5Km grid. I would also think that one should use higher resolution data for nested grids if it is available. So for a 3X grid factor, the 30s (~.9Km) data would best match the ~1.7Km nested grid. For another 3X nesting, maybe topo_wind should be off?

Are there any other WRF input variables that are highly scale-dependent like VAR_SSO? Maybe there is a list somewhere?

Steve

 

[kwerner]

Hi Steve,

I'm very glad that this all makes more sense now. It's definitely helpful when setting up a case. To my knowledge there aren't any other of the static fields that are that dependent on scale, as most of the others, we just always suggest using the highest-resolution available (which is what a setting of 'default' reverts to). The resolution of the meteorological input data should, compared to the resolution of the coarsest domain should not be more than about a 7:1-ish ratio (meaning if it is, you will simply want to consider adding additional outer domains), but other than that, I *think* that's the only thing that matters this much, regarding resolution.

Kelly