[Wrf-users] Question regarding determine some parameters in namelist.wps

[Carlos Ross]

for questions 1 and 2, yes. You just choose dx and dy depending on what is
your final domain (I usually model 1 km, so the first one is 27km, so I
have 27, 9, 3 and 1 km of resolution), and also depends on what is your
input data (in my case, 0,25 degrees)

The next questions:
1) the input is from the geog folder, for geogrid.
2) you just choose 1 time step.
3) there is no constrain, the default is 27 I think, and then you can
choose any other number of vertical levels and set the levels if you want.
e_we must be the same in wps and input.
4) p_top should be less than the top level in your meteorological input.
the default 5000 is 50 mb for example.

You should try the domain wizard to set up your model, it's easier for
choose the domains http://esrl.noaa.gov/gsd/wrfportal/DomainWizard.html




2016-09-06 16:08 GMT-03:00 Zhixuan Cao <hitcaozx at gmail.com>:

> Thank you Carlos.  Could you check the following statements so that I can
> confirm that I understand you correctly.
> 1) So if giving e_we,  e_sn, dx and dy, the dimension of the computation
> domain can be determined, right? Choosing of dx and dy is up to me without
> additional constrain?
> 2) I should only give dx and dy for the first (coarse) domain, and not
> necessary to give that for other child domains because they can be inferred
> from parent_grid_ratio.
>
> I have more other questions (sorry -):
> 1) How could I know what is the input resolution for each domain? More
> specifically, if I am using gfs data, I knew from the file name that the
> resolution can be 0.25 degree, 0.5 degree or 1 degree. What should be the
> corresponding grog_data_res for this case.
>
> 2) Is there any criteria to determine parent_time_step_ratio?
> 3) Is there any constrain on determine e_vert? By constrain, I mean, for
> example, e_we in namelist.input should be consistent with that in
> namelist.wps.  If not, I can determine e_vert based on desired resolution
> in vertical direction?
> 4) How to determine the p_top_requested?
>
> Thank you again.
>
> Zhixuan Cao
>
> On Sep 6, 2016, at 1:47 PM, Carlos Ross <cf.ross at gmail.com> wrote:
>
> Hi Zhixuan,
> You're a bit confused.
>
> e_we and e_sn are the domain dimensions. in X and Y.
> geog_data_res is the resolution of the input data.
> dx and dy are the resolution of the main domain.
> parent_grid_ratio is the ratio starting from the main domain.
>
> As example:
>
>  parent_id         = 1,1,2,
>  parent_grid_ratio = 1,3,3, (resolution of each domain: 27km, 9km, 3km)
>  i_parent_start    = 1,20,15,
>  j_parent_start    = 1,35,15,
>  e_we          = 100,75,60  (domain dimensions: 100x100, 75x75, 60x60
> everyone in grid points)
>  e_sn          = 100,75,60
>  geog_data_res = '10m','5m','2m', (input resolution for each domain)
>  dx = 27000, (first domain resolution)
>  dy = 27000,
>
>
> 2016-09-03 17:57 GMT-03:00 Zhixuan Cao <hitcaozx at gmail.com>:
>
>> Hi
>> I feel confused on the exact meaning of some parameters in namelist.wps,
>> following user manual can not solve my confusion. Could someone give me
>> some advice on this?
>>
>> Here do these following parameters work together to determine the
>> resolution of grids for nested domain simulation?
>> parent_grid_ratio
>> i_parent_start
>> j_parent_start
>> e_we
>> e_sn
>> geog_data_res
>>
>> 1) If geog_data_res gives resolution of grid, then it seems that I do not
>> need e_we and  e_sn.
>> 2) For nested domain simulation, should geog_data_res be consistent with
>> parent_grid_ratio? For example, if parent_grid_ratio = 1, 3 then
>> geog_data_res has to be something like geog_data_res = 9m, 3m.
>> 3) In the tutorial, it says that ( e_we = n* parent_grid_ratio +1) and (
>> e_sn = n* parent_grid_ratio +1).  I guess I can use different n for e_we
>> and  e_sn. Am I right? But is there any constrain on n besides that n has
>> to be a positive integer?
>>
>> Thank you very much!
>>
>> Zhixuan Cao
>>
>> _______________________________________________
>> Wrf-users mailing list
>> Wrf-users at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/wrf-users/attachments/20160906/f79d6c92/attachment-0001.html