[Wrf-users] Question regarding determine some parameters in namelist.wps
曹智选
hitcaozx at gmail.com
Thu Oct 20 17:08:42 MDT 2016
Hi Carlos,
When I go back to refer to your email, I had other three questions:
1) You said in your previous email that "You just choose dx and dy
depending on what is your final domain". To be more explicit. I guess what
you mean is "dx" and "dy" should depends on input meteorological data, but
I can choose parent_grid_ratio and number of nested domains to reach a
desired resolution at the final domain? Am I correct?
2) Does dx and dy have to be EXACTLY consistent with input meteorological
data? I am using some approximation expression to convert resolution in
degree to resolution in km. But even for degree 0.25, I did not get integer
value. So it seems that dx does NOT need to be exactly consistent with
resolution in meteorological data. Then I have a interesting question. For
example, my meteorological is of resolution 1 degree (corresponding
resolution in km is 111 km), can I set dx=30000 (30km) in the namelist?
3) About time_step
It says in the user manual (chapter 5):
http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3.8/users_guide_chap5.htm#restart
a) time_step is "time step for integration seconds (recommended 6*dx in km
for a typical case)" with maximum of 8*dx and minimum of 3*dx.
b) It also says at somewhere else in the user manual that "Make sure that
the time_step is set to comply with the fine-grid domain (typically 6*DX)."
But in an example namelist in chapter 5, they are using the following
parameters: (I am just copy a portion of it here)
&domains
time_step = 180,
max_dom = 1,
e_we = 74, 112, 94,
e_sn = 61, 97, 91,
e_vert = 30, 30, 30,
p_top_requested = 5000,
num_metgrid_levels = 27,
num_metgrid_soil_levels = 4,
dx = 30000, 10000, 3333.33,
dy = 30000, 10000, 3333.33,
Which obviously implies that the time_step in this example is calculated
based on the most coarse grid instead of the finest grid.
What is your opinion over this?
2016-09-06 16:21 GMT-04:00 Carlos Ross <cf.ross at gmail.com>:
> 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/20161020/bd74e060/attachment-0001.html
More information about the Wrf-users
mailing list