# [Met_help] Problems with copygb

John Halley Gotway johnhg at rap.ucar.edu
Thu Oct 4 15:37:09 MDT 2007

```Justin,

I'd say that the WRF mailing list or an email to wrf_help at ucar.edu would
be your best bet.  The MET development team doesn't support copygb.

But I thought I'd take a stab at it anyway.

Let me caution, I've only used copygb a few times.  But your grid
definition does look a little funny to me.  Here's the example from the
CPC website (http://www.cpc.ncep.noaa.gov/products/wesley/copygb.html) for
specifying a lat/lon grid for copygb:

NX = number of points on latitude cirle
NY = number of points on longitude meridian
LAT0 = latitude of origin * 1000  (lat = -90 .. 90)
LON0 = longitude of origin * 1000  (lon=-360 .. 360 ?)
LAT1 = latitude of extreme (last) point * 1000
LON1 = longitude of extreme (last) point * 1000
DX = latitudianal increment * 1000  (sign used)
DY = longitudinal increment * 1000  (sign used)
grid='255 0 NX NY LAT0 LON0 128 LAT1 LAT2 DX DY 64'

In your case (255 0 86 43 40000 276000 128 45880 287900 140 140), you've set:
NX   = 86
NY   = 43
LAT0 = 40000
LON0 = 276000
LAT1 = 45880
LON1 = 287900
DX   = 140
DY   = 140

But what seems odd to me is that your lower left corner (40, 276) plus the
increment*interval doesn't equal the upper right corner (45.88, 287.90).

LAT0 + NX * DX = 40000 + 86 * 140 = 52040 != 45880 (LAT1)
LON0 + NY * DY = 276000 + 43 * 140 = 282020 != 287900 (LON1)

It seems like you'll need to work on the grid definition some more.  Also,
if you look at the example of on the CPC website, the last argument in the
grid definition is the number "64".  I really don't know what the
significance of that is.

Keeping the LAT0, LON0, NX, NY, DX, and DY are unchanged, I'd try
something like:
255 0 86 43 40000 276000 128 52040 282020 140 140 64

Or you could keep the lower-left and upper-right corners fixed and adjust
the NX, NY, DX, and DY values appropriately.

Good luck,
John Halley Gotway
johnhg at ucar.edu

> Good Afternoon,
>
> I am using the copygb utility to regrid some WRF precip (variable:
> apcpsfc) output onto a common grid with another dataset (NCEP Stage 4
> precip) to prepare it for use in the MODE verification software.  I
> noticed that for certain time periods (e.g. forecast hour 1) the grib
> output using bilinear interpolation to the new grid gives me a constant
> "0" field, even though the apcpsfc field in the original grib file is
> nonzero.  My command line input follows:
>
> copygb -g"255 0 86 43 40000 276000 128 45880 287900 140 140" -x
> 2007020700_BGM-ARW.F00100.grb out.grb
>
> The grb file is a 1 hour output file from WRF.  Interestingly, other
> fields, such as tmpprs or prmslmsl seem to go work fine.
> Thinking that the interpolation type might have caused the problem, I
> asked for no interpolation using:
>
> copygb -x 2007020700_BGM-ARW.F00100.grb out.grb
>
> This still gives me a resultant precip field that is filled with zeroes.
>
> Does anyone see anything wrong with my input or how I'm using copygb?  I
>
> I also sent this email along to the WRF email list as copygb is part of
> the WRF  Post-Processor.
>
> Justin Arnott
> NWS Binghamton
> _______________________________________________
> Met_help mailing list
> Met_help at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/met_help
>

```