[Wrf-users] Re: Wrf-users Digest, Vol 34, Issue 10
wrfhelp
wrfhelp at ucar.edu
Thu Jun 28 18:44:02 MDT 2007
Please take a look at the examples in the WRF Software presentation
at WRF tutorial:
http://www.mmm.ucar.edu/wrf/users/tutorial/tutorial_presentation.htm
wrfhelp
On Jun 27, 2007, at 12:00 PM, wrf-users-request at ucar.edu wrote:
> Send Wrf-users mailing list submissions to
> wrf-users at ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
> or, via email, send a message with subject or body 'help' to
> wrf-users-request at ucar.edu
>
> You can reach the person managing the list at
> wrf-users-owner at ucar.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wrf-users digest..."
>
>
> Today's Topics:
>
> 1. Radiation spectrum from GSFC scheme to Surface Driver?
> (unarayan at MIT.EDU)
> 2. Bug in wrfpostproc 2.2.1 NMM centre lon/lat code (Jaakko Hyv?
> tti)
> 3. problem ungribbing NCEP reanalysis in WPS (BRIAN JOSEPH
> MIRETZKY)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 27 Jun 2007 12:06:12 -0400
> From: unarayan at MIT.EDU
> Subject: [Wrf-users] Radiation spectrum from GSFC scheme to Surface
> Driver?
> To: wrf-users at ucar.edu
> Message-ID: <20070627120612.t829j26cwyoks48k at webmail.mit.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello WRF users,
>
> I am interested in obtaining direct and diffuse shortwave radiation in
> uv+visible and IR channels as is computed in the GSFC shortwave
> radiation
> scheme but returned to the Radiation driver as an aggregate GSW (total
> shortwave). How can i return the variables -
> flx,flc,flxu,flxd,fdiruv,fdifuv,fdirpar,fdifpar - from
> module_ra_gsfcsw ? I
> need to pass these variables to a modified lsm. I can declare
> temporary
> variables in solve_em and modify the radiation driver as well as
> module_ra_gsfcsw code but i am looking for a Registry based
> solution, if
> possible. Any help in this matter will be greatly appreciated.
>
> Regards,
> Ujjwal Narayan.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 27 Jun 2007 19:10:05 +0300 (EEST)
> From: Jaakko Hyv?tti <jaakko.hyvatti at iki.fi>
> Subject: [Wrf-users] Bug in wrfpostproc 2.2.1 NMM centre lon/lat code
> To: wrf-users at ucar.edu
> Message-ID: <Pine.LNX.4.64.0706271838360.27700 at mansikka.hyvatti.fi>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi all,
>
> I just stumbled on a bug that with certain grid sizes results in
> incorrect
> coordinates to be stored in output grib gds. The centre longitude is
> shifted one grid point to east or west, resulting in all data being
> shifted in all model grib output. Or more specifically, the resulting
> values are contradictory with the grid corner coordinates, results may
> vary depending on the reading program.
>
> This occurs with current code if (JM+1)/2 = e_sn/2 is even.
>
> Attached is a patch to correct this problem, against
> wrfpostproc_v2.2.1.tar.gz files.
>
> Another bug in the code is, that if the centre point of the domain is
> close to the poles, and the centre point is not a mass point, the
> interpolated latitude coordinate of the centre point is incorrect.
>
> The best solution would be to carry the centre point from global
> attributes in the netcdf file, CEN_LAT and CEN_LON. I have not yet
> checked how to do that or if it will work. Maybe later. And I do not
> know how this relates to nested domains.
>
> Regards,
> Jaakko Hyvätti
> -------------- next part --------------
> diff -ru old/wrfpostprocV2/sorc/wrfpost/INITPOST_NMM.f
> wrfpostprocV2/sorc/wrfpost/INITPOST_NMM.f
> --- old/wrfpostprocV2/sorc/wrfpost/INITPOST_NMM.f 2007-02-21
> 05:07:49.000000000 +0200
> +++ wrfpostprocV2/sorc/wrfpost/INITPOST_NMM.f 2007-06-27
> 18:26:15.000000000 +0300
> @@ -1740,17 +1740,34 @@
> ! pos east
> call collect_loc(gdlat,dummy)
> if(me.eq.0)then
> latstart=nint(dummy(1,1)*1000.)
> latlast=nint(dummy(im,jm)*1000.)
> ! temporary patch for nmm wrf for moving nest. gopal's doing
> + jcen = (jm+1)/2
> if(mod(im,2).ne.0) then
> - icen=(im+1)/2
> - jcen=(jm+1)/2
> - cenlat=nint(dummy(icen,jcen)*1000.)
> + if (mod((jm+1)/2,2).ne.0) then
> + icen=(im+1)/2
> + cenlat=nint(dummy(icen,jcen)*1000.)
> + print*,'case 1',im,jm,icen,jcen,cenlat
> + else
> + icen=(im-1)/2
> + cenlat=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + print*,'WARNING! GRIB CENTRE LATITUDE ONLY APPROXIMATE'
> + print*,'WARNING! ERROR INCREASES NEAR POLES'
> + print*,'case 2',im,jm,icen,jcen,cenlat
> + end if
> else
> - icen=im/2
> - jcen=(jm+1)/2
> - cenlat=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + if (mod((jm+1)/2,2).ne.0) then
> + icen=im/2
> + cenlat=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + print*,'WARNING! GRIB CENTRE LATITUDE ONLY APPROXIMATE'
> + print*,'WARNING! ERROR INCREASES NEAR POLES'
> + print*,'case 3',im,jm,icen,jcen,cenlat
> + else
> + icen=im/2
> + cenlat=nint(dummy(icen,jcen)*1000.)
> + print*,'case 4',im,jm,icen,jcen,cenlat
> + end if
> end if
> end if
> write(6,*) 'laststart,latlast B calling bcast= '
> @@ -1761,17 +1778,30 @@
> +, latstart,latlast
> call collect_loc(gdlon,dummy)
> if(me.eq.0)then
> lonstart=nint(dummy(1,1)*1000.)
> lonlast=nint(dummy(im,jm)*1000.)
> ! temporary patch for nmm wrf for moving nest. gopal's doing
> + jcen = (jm+1)/2
> if(mod(im,2).ne.0) then
> - icen=(im+1)/2
> - jcen=(jm+1)/2
> - cenlon=nint(dummy(icen,jcen)*1000.)
> + if (mod((jm+1)/2,2).ne.0) then
> + icen=(im+1)/2
> + cenlon=nint(dummy(icen,jcen)*1000.)
> + print*,'case 1',im,jm,icen,jcen,cenlon
> + else
> + icen=(im-1)/2
> + cenlon=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + print*,'case 2',im,jm,icen,jcen,cenlon
> + end if
> else
> - icen=im/2
> - jcen=(jm+1)/2
> - cenlon=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + if (mod((jm+1)/2,2).ne.0) then
> + icen=im/2
> + cenlon=nint(0.5*(dummy(icen,jcen)+dummy(icen+1,jcen))
> *1000.)
> + print*,'case 3',im,jm,icen,jcen,cenlon
> + else
> + icen=im/2
> + cenlon=nint(dummy(icen,jcen)*1000.)
> + print*,'case 4',im,jm,icen,jcen,cenlon
> + end if
> end if
> end if
> write(6,*)'lonstart,lonlast B calling bcast= '
>
> ------------------------------
>
> Message: 3
> Date: Wed, 27 Jun 2007 12:56:56 -0500
> From: BRIAN JOSEPH MIRETZKY <bjmiretzky at wisc.edu>
> Subject: [Wrf-users] problem ungribbing NCEP reanalysis in WPS
> To: wrf-users at ucar.edu
> Message-ID: <e5258878fc97.46825e98 at wiscmail.wisc.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Hello WRF users,
>
> I am having problems preforming the ungrib function of the WPS for
> NCEP reanalysis data (NNRP) from 1980. My problems only occurs with
> the 2d surface data, I was successfully able to ungrib the 3d upper
> air data. Here is the error I get, for some reason the utility
> thinks that some of the files I am inputting are grib2 when as far
> as I know they are all grib1.
>
> 2007-06-27 12:54:08.981 --- *** StarStart_date =
> 1980-05-05_00:2007-06-27 12:54:08.981 --- Start_date = 19output
> format is WPS
> Path to intermediate files is ./
> FORTRAN STOP
> ungrib - grib edition num 1
> I was expecting a Grib1 file, but this is a Grib2 file.
> Most likely this is because your GRIBFILE.XXX files
> are not all the same type.
> WPS can handle both file types, but a separate ungrib
> job must be run for each Grib type.
> *** stopping gribcode ***
> ue: 21600 seconds or 6.000000 hours
> 2007-06-27 12:54:08.981 --- Path to intermediate files is ./
> 2007-06-27 12:54:08.982 --- INFORM: Reading Grib Edition 1
>
> Many Thanks,
>
> Brian Miretzky
> University of Wisconsin Graduate Student
>
>
> ------------------------------
>
> _______________________________________________
> Wrf-users mailing list
> Wrf-users at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>
>
> End of Wrf-users Digest, Vol 34, Issue 10
> *****************************************
More information about the Wrf-users
mailing list