Re: Fwd: wrf_map() doesn't put terrain in right place

From: <Eugene.M.Petrescu_at_nyahnyahspammersnyahnyah>
Date: Thu, 10 Jul 2008 23:54:33 +0000 (GMT)

Anton,

One possibility is that we could be seeing somewhat different behavior since we are using lambert conformal for our projection and/or there are other issues involved with the background maps. Among other things.

I measured the westward displacement on a couple of our domains and it works out to be fairly close to 1 dx near the center of the domain. Less up north, and more down south and towards the east and west edges of the domain. Towards the southwest portion of our domains the error is about 2 to 3 dx.
The problem could be a shifted center lon plus the lack of rotation angle info given in the wrf output?

Gene

----- Original Message -----
From: Anton Kulchitsky <kulchits_at_arsc.edu>
Date: Thursday, July 10, 2008 10:55 pm
Subject: Re: [ncl-talk] Fwd: wrf_map() doesn't put terrain in right place
To: gene <Eugene.M.Petrescu_at_noaa.gov>
Cc: Mary Haley <haley_at_ucar.edu>, Don Morton <donaldjmorton_at_gmail.com>, ncl forum <ncl-talk_at_ucar.edu>, Paul Suffern <Paul.Suffern_at_noaa.gov>, Carl Dierking <carl.dierking_at_noaa.gov>, UAF Smoke Group <uafsmoke_at_arsc.edu>, wrfhelp_at_ucar.edu

> Well, if I may intrude upon your conversation... It seems that the
> shift is more than just dx. In our case, dx=5km and the shift is
>
> 1) bigger
>
> 2) is not uniform over the plot
>
> The example is at - correct
> fires locations vs. - incorrect
> WRF output representation.
>
> We suspect that because scales and fires in scales are plotted
> properly, while cities and boundaries are shifted/rotated/scaled,
> boundaries with cities are just plotted in different projection
> (default for ncl?) while the data are plotted with the projection data
> set in netCDF. What do you think?
>
> Regards,
>
> Anton
>
>
> gene <Eugene.M.Petrescu_at_noaa.gov> writes:
>
> > I was searching through some old WRF e-mails and came across this one
> > from last year. This error seems to correspond exactly with the
> > troubles we are seeing, a westward shift in the data fields and
> > terrain by about 1 dx. This problem seems to be in the raw WRF
> > output which then gets into grib output as well.
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > 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
> >
> > ------------------------------------------------------------------------
> >
> > 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= '
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > Mary Haley wrote:
> >>
> >> Hi Don,
> >>
> >> I remember this thread, but I'm afraid I don't remember where we left
> >> it. (Or did we completely drop the ball on it?!)
> >>
> >> Anyway, one thing I have seen occasionally is that the WRF data file
> >> has the wrong center longitude value, and hence the map projection
> >> and the data don't line up quite right. I'm not sure NCL can do anything
> >> to detect this.
> >>
> >> Can you provide a sample dataset and script for us to look at?
> >>
> >> --Mary
> >>
> >>
> >> On Thu, 10 Jul 2008, Don Morton wrote:
> >>
> >>> Hi all,
> >>>
> >>> I decided to politely re-surface the following thread :) It seems
> like
> >>> colleagues are running into this issue more and more, and I'm
> >>> afraid I don't
> >>> know enough to say much more than that for some reason the WRF domains
> >>> aren't plotted correctly by a number of software packages,
> >>> including the NCL
> >>> WRF functions (and, we've learned recently, GEMPAK). Is there a
> >>> way that we
> >>> out here in the trenches might be wanting to define our original
> >>> domains to
> >>> avoid these problems?
> >>>
> >>> Thanks,
> >>>
> >>> Don
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Don Morton <donaldjmorton_at_gmail.com>
> >>> Date: Thu, May 1, 2008 at 10:16 PM
> >>> Subject: wrf_map() doesn't put terrain in right place
> >>> To: ncl forum <ncl-talk_at_ucar.edu>, wrfhelp <wrfhelp_at_ucar.edu>
> >>>
> >>>
> >>> Hi, here's another problem I've been running into lately -
> >>> it's very similar to one I had last summer, that you all helped
> >>> me find a fix for.
> >>>
> >>> I'm trying to use the newer wrf NCL functions, as I really like
> >>> their potential ease of use. However, in trying to do a simple
> >>> terrain plot on a WRF nest, the terrain ends up in the wrong
> >>> place. The script is available at
> >>>
> >>> <>
> >>>
> >>> and the input data, "wrfoutd02.nc" is in the same directory.
> >>> The resulting image is at
> >>>
> >>> <>
> >>>
> >>> You can see that the Alaska Range has moved to the Gulf of Alaska.
> >>>
> >>> This is presumably because the WRF output file represents an inner
> >>> nest of a larger domain, and in this nest the Standard Lon and the
> >>> Center Lon are different. This "seems" like a common occurrence
> to me,
> >>> unless you place the nest smack in the middle of the parent?
> >>>
> >>> Last summer, you all helped me fix this issue, and such a
> >>> script exists at
> >>>
> >>> <>
> >>>
> >>> with resulting image at
> >>>
> >>> <>
> >>>
> >>> I tried playing around with some resource settings for the wrf_map()
> >>> functions, but couldn't get anything to work.
> >>>
> >>> Thanks,
> >>>
> >>> Don
> >>> --
> >>> University of Montana
> >>> >
> >>> Arctic Region Supercomputing Center
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Arctic Region Supercomputing Center
> >>>
> >>> University of Montana
> >>>
> >>>
> >
>
> --
> There is no place like ~
>
> Anton Kulchitsky, PhD
> HPC Specialist
> University of Alaska Fairbanks,
> Arctic Region Supercomputing Center
> West Ridge Research Building
> 909 Koyukuk Drive, Suite 105
> PO Box 756020 Fairbanks, AK 99775-6020
> Tel. (907)450-8689 Fax. (907)450-8603
> E-mail: kulchits_at_arsc.edu
Received on Thu Jul 10 2008 - 17:54:33 MDT

This archive was generated by hypermail 2.2.0 : Fri Jul 11 2008 - 11:22:42 MDT