[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