[Wrf-users] more WRF 3.2 issues: delayed initialization of nests and fine_input_stream

wrfhelp wrfhelp at ucar.edu
Mon Apr 19 15:43:58 MDT 2010


In V3.2, when you use auxiliary input such as this input option  
(fine_input_stream = 0, 2, implies
that you are using auxiliary input stream 2), you need to set the  
io_form for it to define the data format.
In this case, add io_form_auxinput2 = 2 in &time_control. In previous  
versions, it was set in the registry by
default. This is a result of expanded IO capability in other areas.

wrfhelp

On Apr 19, 2010, at 1:37 PM, wrf-users-owner at ucar.edu wrote:

>
> From: "Zulauf, Michael" <Michael.Zulauf at iberdrolausa.com>
> Date: April 19, 2010 1:36:31 PM MDT
> To: <wrf-users at ucar.edu>
> Subject: more WRF 3.2 issues: delayed initialization of nests and  
> fine_input_stream
>
>
> Hi again, WRF users. . .
>
> I've come across another issue with WRF V3.2 that seemed to work fine
> with WRF V3.1.1 and earlier.  The netcdf problems I mentioned earlier
> continue, but playing with optimization does seem to have an impact.
> I'm hopeful that I'll find some settings that have reasonable
> performance and also don't hang occasionally on netcdf output.  The  
> new
> issue seems separate.
>
> I delay the initialization of the inner grids in the model runs I
> described earlier (outer domain at 27 km, nests at 9km, 3km and 1km).
> The nest initializations are delayed by 3 hours, 6 hours, and 9  
> hours -
> times which coincide with the GFS input data.  I believe I have set
> input_from_file  and fine_input_stream so that static data like
> topography comes from the wrfinput_d0x files, and the atmospheric data
> is interpolated from the parent grid.  Ie:
> 	input_from_file                     =
> .true.,.true.,.true.,.true.,.true.,
> 	fine_input_stream                   = 0, 2, 2, 2,
>
> But when I look at the wrfout files, it looks like _all_ of the data  
> is
> being interpolated from the parent grid, so we get no benefit of the
> higher resolution topography.  The high resolution topography is in  
> the
> wrfinput_d0x files, and the time of the data appears to be correct (at
> the time that the nests are supposed to initialize).
>
> When run with V3.1.1, I see the high resolution topography in both the
> input and output files, as I should.
>
> I've also found that if I use V3.2 and initialize the nests at the  
> same
> time as the outer domain (at the beginning), it also seems to work  
> fine
> then.  So it only seems to be a problem (for me) when I use delayed
> initialization with the nests.
>
> Any thoughts?
>
> Thanks,
> Mike
>
> -- 
> Mike Zulauf
> Meteorologist
> Wind Asset Management
> Iberdrola Renewables
> 1125 NW Couch, Suite 700
> Portland, OR 97209
> Office: 503-478-6304  Cell: 503-913-0403
>
>
>
>
>
>
> This message is intended for the exclusive attention of the  
> address(es) indicated.  Any information contained herein is strictly  
> confidential and privileged, especially as regards person data,
> which must not be disclosed.  If you are the intended recipient and  
> have received it by mistake or learn about it in any other way,  
> please notify us by return e-mail and delete this message from
> your computer system. Any unauthorized use, reproduction,  
> alteration, filing or sending of this message and/or any attached  
> files to third parties may lead to legal proceedings being taken. Any
> opinion expressed herein is solely that of the author(s) and does  
> not necessarily represent the opinion of Iberdrola. The sender does  
> not guarantee the integrity, speed or safety of this
> message, not accept responsibility for any possible damage arising  
> from the interception, incorporation of virus or any other  
> manipulation carried out by third parties.
>
>
>
>
> From: wrf-users-request at ucar.edu
> Subject: confirm a9448315ac5eefb4c2c7881d644974406675c9fe
>
>
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for posting
> to the list.  The Approved: header can also appear in the first line
> of the body of the reply.
>

wrfhelp
http://www.mmm.ucar.edu/wrf/users/supports/wrfhelp.html





More information about the Wrf-users mailing list