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

All,

This is being looked at by the wrfhelp folks, and they are
going to provide us with a fix to include in the next release
of NCL.

--Mary

On Fri, 11 Jul 2008, Don Morton wrote:

> Gene, et. al. [I took NCL Forum off the address list for now]

I'll collect the "problem" files for Mary and wrfhelp. Gene, I'll send you
instructions on uploading one from KMSO to my UM machine if you're willing.
I'll take a look at the Juneau files, too (I haven't yet). Boy, this is
gonna be a fun weekend :) I got a private response from someone suggesting
I can print out all the map resources, and I'll look into that.

Mary - I do tend to agree this isn't so much an NCL problem, but it "does"
manifest itself in the new WRF NCL functions. For a preliminary view, I can
point you to the directory I posted with the original comment...

http://weather.arsc.edu/Miscellaneous/NCL/Maps/

In there, Image1.jpg and wrfHGT-1.ncl are the "bad" files, and Image2.jpg
and wrfHGT-2.jpg are the "good" files (it's the approach you NCL'ers pointed
me to over a year ago, which has worked fine for me).

On Thu, Jul 10, 2008 at 11:54 PM, <Eugene.M.Petrescu_at_noaa.gov> wrote:

> 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: 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
>

-- 
Arctic Region Supercomputing Center
http://weather.arsc.edu/
University of Montana
http://www.cs.umt.edu/~morton/

_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Fri Jul 11 2008 - 09:49:15 MDT