[Met_help] [rt.rap.ucar.edu #63081] History for question about using copygb.exe

Tue Sep 24 09:58:19 MDT 2013

----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hi CS,

I would like to use NARR data and my WRF output to do grid_stat.

MY model output is in polar projection and domain is Alaska region. I
convert the WRF output  into grib by UPPV2.1,  then I use

copygb.exe -xg221 ingribfile outgribfile

It can complete partial record conversion. ingribfile have 349 records,
outgribfile only include 294 records,  and it shows the error: Floating
point exception.

Can you tell me how I can overcome the problem. I want to eliminate some
fields that cause problem, but I don't know what fields have problem in
ingribfile.

I can upload these two files for you to take a look at the problem.

Thank you very much in advance.

Jiang

-- 
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: Re: [rt.rap.ucar.edu #63081] question about using copygb.exe
From: John Halley Gotway
Time: Thu Sep 19 09:59:52 2013

Jiang,

Yes, I suspect that there's a record that's causing copygb to abort
and give you an incomplete file.  Please post your data to our
anonymous ftp site following these instructions:
    http://www.dtcenter.org/met/users/support/met_help.php#ftp

I'll take a look and will hopefully be able to provide you with a
work-around.  Ultimately, it'd be better if we were able to update
copygb to avoid the floating point exception.  But realistically,
it'll probably be easier to just avoid processing the record that's
causing it.

Thanks,
John Halley Gotway
met_help at ucar.edu

On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>
> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> Transaction: Ticket created by jiang at gina.alaska.edu
>         Queue: met_help
>       Subject: question about using copygb.exe
>         Owner: Nobody
>    Requestors: jiang at gina.alaska.edu
>        Status: new
>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>
>
> Hi CS,
>
> I would like to use NARR data and my WRF output to do grid_stat.
>
> MY model output is in polar projection and domain is Alaska region.
I
> convert the WRF output  into grib by UPPV2.1,  then I use
>
> copygb.exe -xg221 ingribfile outgribfile
>
> It can complete partial record conversion. ingribfile have 349
records,
> outgribfile only include 294 records,  and it shows the error:
Floating
> point exception.
>
> Can you tell me how I can overcome the problem. I want to eliminate
some
> fields that cause problem, but I don't know what fields have problem
in
> ingribfile.
>
> I can upload these two files for you to take a look at the problem.
>
>
> Thank you very much in advance.
>
> Jiang
>

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Thu Sep 19 11:56:52 2013

Hi John,

I uploaded three files. One is grib file produced from wrfout by
UPPV2.1
(gribbyuppv21), another is    regridded grib file by copygb.exe
(gribbyuppv21_copygb_221), the third file is parm file used to control
convert wrfout to grib file by UPPV2.1.

I read your previous online post which was related to my question. You
suggested change parm file not to output problem-making variables
(fields).
The question is I don't know which variables cause the problem. Hope
you
can help me.

Thank you!

Jiang

On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jiang,
>
> Yes, I suspect that there's a record that's causing copygb to abort
and
> give you an incomplete file.  Please post your data to our anonymous
ftp
> site following these instructions:
>     http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> I'll take a look and will hopefully be able to provide you with a
> work-around.  Ultimately, it'd be better if we were able to update
copygb
> to avoid the floating point exception.  But realistically,
> it'll probably be easier to just avoid processing the record that's
> causing it.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
> >
> > Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> > Transaction: Ticket created by jiang at gina.alaska.edu
> >         Queue: met_help
> >       Subject: question about using copygb.exe
> >         Owner: Nobody
> >    Requestors: jiang at gina.alaska.edu
> >        Status: new
> >   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >
> >
> > Hi CS,
> >
> > I would like to use NARR data and my WRF output to do grid_stat.
> >
> > MY model output is in polar projection and domain is Alaska
region. I
> > convert the WRF output  into grib by UPPV2.1,  then I use
> >
> > copygb.exe -xg221 ingribfile outgribfile
> >
> > It can complete partial record conversion. ingribfile have 349
records,
> > outgribfile only include 294 records,  and it shows the error:
Floating
> > point exception.
> >
> > Can you tell me how I can overcome the problem. I want to
eliminate some
> > fields that cause problem, but I don't know what fields have
problem in
> > ingribfile.
> >
> > I can upload these two files for you to take a look at the
problem.
> >
> >
> > Thank you very much in advance.
> >
> > Jiang
> >
>
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #63081] question about using copygb.exe
From: John Halley Gotway
Time: Thu Sep 19 15:08:49 2013

Jiang,

The problem is being caused by record number 294 for the GRIB code
PEVAP.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Here's what I did to test this...

# Use wgrib to list records in the two GRIB files you sent:
wgrib gribbyUPPV21 > gribbyUPPV21.inv
wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv

# Compared them and saw that the copygb output ends at record 293.
# Copied over the list of records and removed the line for PEVAP
cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list

# Run wgrib to subset the GRIB file to get rid of the PEVAP record
wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list

# Run the subsetted file through copygb to make sure it processes all
the other records
copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221

# Use wgrib to make sure that the output has all 348 (= 349 - 1) of
the expected records
wgrib gribbyUPPV21_subset_221 | wc -l

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So it is definitely the PEVAP record that's causing the problem.
You're right, you could modify the wrf_cntrl.parm file to skip this
record from being output by UPP.  I believe that PEVAP stands for
"potential evaporation".  So I'd suggest modifying wrf_cntrl.parm to
use the following line:

  (ACC POT EVAPORATION ) SCAL=( 4.0)
  L=(00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
00000 00000 00000)

Changing the 1 that was there to a 0 should disable it's output.

Hope that helps.

Thanks,
John

On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>
> Hi John,
>
> I uploaded three files. One is grib file produced from wrfout by
UPPV2.1
> (gribbyuppv21), another is    regridded grib file by copygb.exe
> (gribbyuppv21_copygb_221), the third file is parm file used to
control
> convert wrfout to grib file by UPPV2.1.
>
> I read your previous online post which was related to my question.
You
> suggested change parm file not to output problem-making variables
(fields).
> The question is I don't know which variables cause the problem. Hope
you
> can help me.
>
> Thank you!
>
> Jiang
>
>
> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jiang,
>>
>> Yes, I suspect that there's a record that's causing copygb to abort
and
>> give you an incomplete file.  Please post your data to our
anonymous ftp
>> site following these instructions:
>>      http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> I'll take a look and will hopefully be able to provide you with a
>> work-around.  Ultimately, it'd be better if we were able to update
copygb
>> to avoid the floating point exception.  But realistically,
>> it'll probably be easier to just avoid processing the record that's
>> causing it.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>>>
>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
>>> Transaction: Ticket created by jiang at gina.alaska.edu
>>>          Queue: met_help
>>>        Subject: question about using copygb.exe
>>>          Owner: Nobody
>>>     Requestors: jiang at gina.alaska.edu
>>>         Status: new
>>>    Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>
>>>
>>> Hi CS,
>>>
>>> I would like to use NARR data and my WRF output to do grid_stat.
>>>
>>> MY model output is in polar projection and domain is Alaska
region. I
>>> convert the WRF output  into grib by UPPV2.1,  then I use
>>>
>>> copygb.exe -xg221 ingribfile outgribfile
>>>
>>> It can complete partial record conversion. ingribfile have 349
records,
>>> outgribfile only include 294 records,  and it shows the error:
Floating
>>> point exception.
>>>
>>> Can you tell me how I can overcome the problem. I want to
eliminate some
>>> fields that cause problem, but I don't know what fields have
problem in
>>> ingribfile.
>>>
>>> I can upload these two files for you to take a look at the
problem.
>>>
>>>
>>> Thank you very much in advance.
>>>
>>> Jiang
>>>
>>
>>
>
>

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Thu Sep 19 16:10:55 2013

Hi John,

Thank you very much. I delete the line you suggested and re do it, it
works! In fact, Since I only uses some variables to compare with NARR
data,
I delete many variables in wrf_control file. It is a good way to work
raound the problem.

I got another question: I copygb grib-ormatted wrfout file into G221
in
order to use grid-stat tool to compare with NARR data (G221). The
domain of
my WRF is alaska region, but the NARR is whole north america, do I
need set
mask in the configuration file for doing grid-stat? If yes, how do I
set
the mask? Can I just set rectangular area with lon and lat?

Thank you very much,

Jiang

On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jiang,
>
> The problem is being caused by record number 294 for the GRIB code
PEVAP.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Here's what I did to test this...
>
> # Use wgrib to list records in the two GRIB files you sent:
> wgrib gribbyUPPV21 > gribbyUPPV21.inv
> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
>
> # Compared them and saw that the copygb output ends at record 293.
> # Copied over the list of records and removed the line for PEVAP
> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
>
> # Run wgrib to subset the GRIB file to get rid of the PEVAP record
> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list
>
> # Run the subsetted file through copygb to make sure it processes
all the
> other records
> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
>
> # Use wgrib to make sure that the output has all 348 (= 349 - 1) of
the
> expected records
> wgrib gribbyUPPV21_subset_221 | wc -l
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> So it is definitely the PEVAP record that's causing the problem.
You're
> right, you could modify the wrf_cntrl.parm file to skip this record
from
> being output by UPP.  I believe that PEVAP stands for
> "potential evaporation".  So I'd suggest modifying wrf_cntrl.parm to
use
> the following line:
>
>   (ACC POT EVAPORATION ) SCAL=( 4.0)
>   L=(00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
00000
> 00000 00000 00000)
>
> Changing the 1 that was there to a 0 should disable it's output.
>
> Hope that helps.
>
> Thanks,
> John
>
> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >
> > Hi John,
> >
> > I uploaded three files. One is grib file produced from wrfout by
UPPV2.1
> > (gribbyuppv21), another is    regridded grib file by copygb.exe
> > (gribbyuppv21_copygb_221), the third file is parm file used to
control
> > convert wrfout to grib file by UPPV2.1.
> >
> > I read your previous online post which was related to my question.
You
> > suggested change parm file not to output problem-making variables
> (fields).
> > The question is I don't know which variables cause the problem.
Hope you
> > can help me.
> >
> > Thank you!
> >
> > Jiang
> >
> >
> > On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jiang,
> >>
> >> Yes, I suspect that there's a record that's causing copygb to
abort and
> >> give you an incomplete file.  Please post your data to our
anonymous ftp
> >> site following these instructions:
> >>      http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>
> >> I'll take a look and will hopefully be able to provide you with a
> >> work-around.  Ultimately, it'd be better if we were able to
update
> copygb
> >> to avoid the floating point exception.  But realistically,
> >> it'll probably be easier to just avoid processing the record
that's
> >> causing it.
> >>
> >> Thanks,
> >> John Halley Gotway
> >> met_help at ucar.edu
> >>
> >> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
> >>>
> >>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> >>> Transaction: Ticket created by jiang at gina.alaska.edu
> >>>          Queue: met_help
> >>>        Subject: question about using copygb.exe
> >>>          Owner: Nobody
> >>>     Requestors: jiang at gina.alaska.edu
> >>>         Status: new
> >>>    Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>
> >>>
> >>> Hi CS,
> >>>
> >>> I would like to use NARR data and my WRF output to do grid_stat.
> >>>
> >>> MY model output is in polar projection and domain is Alaska
region. I
> >>> convert the WRF output  into grib by UPPV2.1,  then I use
> >>>
> >>> copygb.exe -xg221 ingribfile outgribfile
> >>>
> >>> It can complete partial record conversion. ingribfile have 349
records,
> >>> outgribfile only include 294 records,  and it shows the error:
Floating
> >>> point exception.
> >>>
> >>> Can you tell me how I can overcome the problem. I want to
eliminate
> some
> >>> fields that cause problem, but I don't know what fields have
problem in
> >>> ingribfile.
> >>>
> >>> I can upload these two files for you to take a look at the
problem.
> >>>
> >>>
> >>> Thank you very much in advance.
> >>>
> >>> Jiang
> >>>
> >>
> >>
> >
> >
>
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------
Subject: question about using copygb.exe
From: John Halley Gotway
Time: Thu Sep 19 16:48:20 2013

Jiang,

I used the plot_data_plane tool to visualize your data.  I plotted 2-m
temperature:
    METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'

I converted the resulting postscript file to a png, and it is
attached.  Looks like we've got a bit of an issue in plotting the map
data, but other than that, the data looks good.  So this data is on
grid 221 but only contains valid data over Alaska.

Since your forecast and observation data are on the same grid, you can
pass them directly to Grid-Stat.  Grid-Stat will only compute
statistics where the forecast and observation values are both
valid.  So the stats will only be computed over the Alaska region.
You do not need to specify a masking region.

However, if Grid-Stat runs slowly, providing a masking region could
speed it up.  For example, if you choose multiple smoothing methods
(interp.type.method and interp.type.width), computing those over
the entire observation field could be slow.  But I'd say, just try
running without a mask and use the "FULL" domain.  If it runs fast
enough, I think you're fine.

Thanks,
John

On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>
> Hi John,
>
> Thank you very much. I delete the line you suggested and re do it,
it
> works! In fact, Since I only uses some variables to compare with
NARR data,
> I delete many variables in wrf_control file. It is a good way to
work
> raound the problem.
>
> I got another question: I copygb grib-ormatted wrfout file into G221
in
> order to use grid-stat tool to compare with NARR data (G221). The
domain of
> my WRF is alaska region, but the NARR is whole north america, do I
need set
> mask in the configuration file for doing grid-stat? If yes, how do I
set
> the mask? Can I just set rectangular area with lon and lat?
>
> Thank you very much,
>
> Jiang
>
>
> On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jiang,
>>
>> The problem is being caused by record number 294 for the GRIB code
PEVAP.
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Here's what I did to test this...
>>
>> # Use wgrib to list records in the two GRIB files you sent:
>> wgrib gribbyUPPV21 > gribbyUPPV21.inv
>> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
>>
>> # Compared them and saw that the copygb output ends at record 293.
>> # Copied over the list of records and removed the line for PEVAP
>> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
>>
>> # Run wgrib to subset the GRIB file to get rid of the PEVAP record
>> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list
>>
>> # Run the subsetted file through copygb to make sure it processes
all the
>> other records
>> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
>>
>> # Use wgrib to make sure that the output has all 348 (= 349 - 1) of
the
>> expected records
>> wgrib gribbyUPPV21_subset_221 | wc -l
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> So it is definitely the PEVAP record that's causing the problem.
You're
>> right, you could modify the wrf_cntrl.parm file to skip this record
from
>> being output by UPP.  I believe that PEVAP stands for
>> "potential evaporation".  So I'd suggest modifying wrf_cntrl.parm
to use
>> the following line:
>>
>>    (ACC POT EVAPORATION ) SCAL=( 4.0)
>>    L=(00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
00000
>> 00000 00000 00000)
>>
>> Changing the 1 that was there to a 0 should disable it's output.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>
>>> Hi John,
>>>
>>> I uploaded three files. One is grib file produced from wrfout by
UPPV2.1
>>> (gribbyuppv21), another is    regridded grib file by copygb.exe
>>> (gribbyuppv21_copygb_221), the third file is parm file used to
control
>>> convert wrfout to grib file by UPPV2.1.
>>>
>>> I read your previous online post which was related to my question.
You
>>> suggested change parm file not to output problem-making variables
>> (fields).
>>> The question is I don't know which variables cause the problem.
Hope you
>>> can help me.
>>>
>>> Thank you!
>>>
>>> Jiang
>>>
>>>
>>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Jiang,
>>>>
>>>> Yes, I suspect that there's a record that's causing copygb to
abort and
>>>> give you an incomplete file.  Please post your data to our
anonymous ftp
>>>> site following these instructions:
>>>>       http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>
>>>> I'll take a look and will hopefully be able to provide you with a
>>>> work-around.  Ultimately, it'd be better if we were able to
update
>> copygb
>>>> to avoid the floating point exception.  But realistically,
>>>> it'll probably be easier to just avoid processing the record
that's
>>>> causing it.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> met_help at ucar.edu
>>>>
>>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>>>>>
>>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
>>>>> Transaction: Ticket created by jiang at gina.alaska.edu
>>>>>           Queue: met_help
>>>>>         Subject: question about using copygb.exe
>>>>>           Owner: Nobody
>>>>>      Requestors: jiang at gina.alaska.edu
>>>>>          Status: new
>>>>>     Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>>
>>>>>
>>>>> Hi CS,
>>>>>
>>>>> I would like to use NARR data and my WRF output to do grid_stat.
>>>>>
>>>>> MY model output is in polar projection and domain is Alaska
region. I
>>>>> convert the WRF output  into grib by UPPV2.1,  then I use
>>>>>
>>>>> copygb.exe -xg221 ingribfile outgribfile
>>>>>
>>>>> It can complete partial record conversion. ingribfile have 349
records,
>>>>> outgribfile only include 294 records,  and it shows the error:
Floating
>>>>> point exception.
>>>>>
>>>>> Can you tell me how I can overcome the problem. I want to
eliminate
>> some
>>>>> fields that cause problem, but I don't know what fields have
problem in
>>>>> ingribfile.
>>>>>
>>>>> I can upload these two files for you to take a look at the
problem.
>>>>>
>>>>>
>>>>> Thank you very much in advance.
>>>>>
>>>>> Jiang
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Thu Sep 19 17:54:46 2013

Hi John,

You are such a great helper! Actually, I will use poly files to mask
to
evaluate my model in several areas in Alaska.

Thank you very much!

Jiang

On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jiang,
>
> I used the plot_data_plane tool to visualize your data.  I plotted
2-m
> temperature:
>     METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
>
> I converted the resulting postscript file to a png, and it is
attached.
>  Looks like we've got a bit of an issue in plotting the map data,
but other
> than that, the data looks good.  So this data is on
> grid 221 but only contains valid data over Alaska.
>
> Since your forecast and observation data are on the same grid, you
can
> pass them directly to Grid-Stat.  Grid-Stat will only compute
statistics
> where the forecast and observation values are both
> valid.  So the stats will only be computed over the Alaska region.
You do
> not need to specify a masking region.
>
> However, if Grid-Stat runs slowly, providing a masking region could
speed
> it up.  For example, if you choose multiple smoothing methods
> (interp.type.method and interp.type.width), computing those over
> the entire observation field could be slow.  But I'd say, just try
running
> without a mask and use the "FULL" domain.  If it runs fast enough, I
think
> you're fine.
>
> Thanks,
> John
>
> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >
> > Hi John,
> >
> > Thank you very much. I delete the line you suggested and re do it,
it
> > works! In fact, Since I only uses some variables to compare with
NARR
> data,
> > I delete many variables in wrf_control file. It is a good way to
work
> > raound the problem.
> >
> > I got another question: I copygb grib-ormatted wrfout file into
G221 in
> > order to use grid-stat tool to compare with NARR data (G221). The
domain
> of
> > my WRF is alaska region, but the NARR is whole north america, do I
need
> set
> > mask in the configuration file for doing grid-stat? If yes, how do
I set
> > the mask? Can I just set rectangular area with lon and lat?
> >
> > Thank you very much,
> >
> > Jiang
> >
> >
> > On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jiang,
> >>
> >> The problem is being caused by record number 294 for the GRIB
code
> PEVAP.
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >> Here's what I did to test this...
> >>
> >> # Use wgrib to list records in the two GRIB files you sent:
> >> wgrib gribbyUPPV21 > gribbyUPPV21.inv
> >> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
> >>
> >> # Compared them and saw that the copygb output ends at record
293.
> >> # Copied over the list of records and removed the line for PEVAP
> >> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
> >>
> >> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
> >> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list
> >>
> >> # Run the subsetted file through copygb to make sure it processes
all
> the
> >> other records
> >> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
> >>
> >> # Use wgrib to make sure that the output has all 348 (= 349 - 1)
of the
> >> expected records
> >> wgrib gribbyUPPV21_subset_221 | wc -l
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >> So it is definitely the PEVAP record that's causing the problem.
You're
> >> right, you could modify the wrf_cntrl.parm file to skip this
record from
> >> being output by UPP.  I believe that PEVAP stands for
> >> "potential evaporation".  So I'd suggest modifying wrf_cntrl.parm
to use
> >> the following line:
> >>
> >>    (ACC POT EVAPORATION ) SCAL=( 4.0)
> >>    L=(00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
00000
> >> 00000 00000 00000)
> >>
> >> Changing the 1 that was there to a 0 should disable it's output.
> >>
> >> Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>
> >>> Hi John,
> >>>
> >>> I uploaded three files. One is grib file produced from wrfout by
> UPPV2.1
> >>> (gribbyuppv21), another is    regridded grib file by copygb.exe
> >>> (gribbyuppv21_copygb_221), the third file is parm file used to
control
> >>> convert wrfout to grib file by UPPV2.1.
> >>>
> >>> I read your previous online post which was related to my
question. You
> >>> suggested change parm file not to output problem-making
variables
> >> (fields).
> >>> The question is I don't know which variables cause the problem.
Hope
> you
> >>> can help me.
> >>>
> >>> Thank you!
> >>>
> >>> Jiang
> >>>
> >>>
> >>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
> >>> met_help at ucar.edu> wrote:
> >>>
> >>>> Jiang,
> >>>>
> >>>> Yes, I suspect that there's a record that's causing copygb to
abort
> and
> >>>> give you an incomplete file.  Please post your data to our
anonymous
> ftp
> >>>> site following these instructions:
> >>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>>>
> >>>> I'll take a look and will hopefully be able to provide you with
a
> >>>> work-around.  Ultimately, it'd be better if we were able to
update
> >> copygb
> >>>> to avoid the floating point exception.  But realistically,
> >>>> it'll probably be easier to just avoid processing the record
that's
> >>>> causing it.
> >>>>
> >>>> Thanks,
> >>>> John Halley Gotway
> >>>> met_help at ucar.edu
> >>>>
> >>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
> >>>>>
> >>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> >>>>> Transaction: Ticket created by jiang at gina.alaska.edu
> >>>>>           Queue: met_help
> >>>>>         Subject: question about using copygb.exe
> >>>>>           Owner: Nobody
> >>>>>      Requestors: jiang at gina.alaska.edu
> >>>>>          Status: new
> >>>>>     Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>>>
> >>>>>
> >>>>> Hi CS,
> >>>>>
> >>>>> I would like to use NARR data and my WRF output to do
grid_stat.
> >>>>>
> >>>>> MY model output is in polar projection and domain is Alaska
region. I
> >>>>> convert the WRF output  into grib by UPPV2.1,  then I use
> >>>>>
> >>>>> copygb.exe -xg221 ingribfile outgribfile
> >>>>>
> >>>>> It can complete partial record conversion. ingribfile have 349
> records,
> >>>>> outgribfile only include 294 records,  and it shows the error:
> Floating
> >>>>> point exception.
> >>>>>
> >>>>> Can you tell me how I can overcome the problem. I want to
eliminate
> >> some
> >>>>> fields that cause problem, but I don't know what fields have
problem
> in
> >>>>> ingribfile.
> >>>>>
> >>>>> I can upload these two files for you to take a look at the
problem.
> >>>>>
> >>>>>
> >>>>> Thank you very much in advance.
> >>>>>
> >>>>> Jiang
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Fri Sep 20 14:16:29 2013

Hi John,

I got another general questions to ask your advice. When I use MET
grid-stat tool to compare my model run (with Polar stero projection,
18 km
resolution) with NARR (with G221 projection grid, lambert conf, 32 km
resolution),  should I convert NARR data to polar steoro or vise
versa? and
what interpolation method should I use?

Thank you for your advice!

Jiang

On Thu, Sep 19, 2013 at 3:54 PM, Jiang Zhu <jiang at gina.alaska.edu>
wrote:

> Hi John,
>
> You are such a great helper! Actually, I will use poly files to mask
to
> evaluate my model in several areas in Alaska.
>
> Thank you very much!
>
> Jiang
>
>
>
>
> On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jiang,
>>
>> I used the plot_data_plane tool to visualize your data.  I plotted
2-m
>> temperature:
>>     METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
>> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
>>
>> I converted the resulting postscript file to a png, and it is
attached.
>>  Looks like we've got a bit of an issue in plotting the map data,
but other
>> than that, the data looks good.  So this data is on
>> grid 221 but only contains valid data over Alaska.
>>
>> Since your forecast and observation data are on the same grid, you
can
>> pass them directly to Grid-Stat.  Grid-Stat will only compute
statistics
>> where the forecast and observation values are both
>> valid.  So the stats will only be computed over the Alaska region.
You
>> do not need to specify a masking region.
>>
>> However, if Grid-Stat runs slowly, providing a masking region could
speed
>> it up.  For example, if you choose multiple smoothing methods
>> (interp.type.method and interp.type.width), computing those over
>> the entire observation field could be slow.  But I'd say, just try
>> running without a mask and use the "FULL" domain.  If it runs fast
enough,
>> I think you're fine.
>>
>> Thanks,
>> John
>>
>> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>> >
>> > Hi John,
>> >
>> > Thank you very much. I delete the line you suggested and re do
it, it
>> > works! In fact, Since I only uses some variables to compare with
NARR
>> data,
>> > I delete many variables in wrf_control file. It is a good way to
work
>> > raound the problem.
>> >
>> > I got another question: I copygb grib-ormatted wrfout file into
G221 in
>> > order to use grid-stat tool to compare with NARR data (G221). The
>> domain of
>> > my WRF is alaska region, but the NARR is whole north america, do
I need
>> set
>> > mask in the configuration file for doing grid-stat? If yes, how
do I set
>> > the mask? Can I just set rectangular area with lon and lat?
>> >
>> > Thank you very much,
>> >
>> > Jiang
>> >
>> >
>> > On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Jiang,
>> >>
>> >> The problem is being caused by record number 294 for the GRIB
code
>> PEVAP.
>> >>
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>
>> >> Here's what I did to test this...
>> >>
>> >> # Use wgrib to list records in the two GRIB files you sent:
>> >> wgrib gribbyUPPV21 > gribbyUPPV21.inv
>> >> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
>> >>
>> >> # Compared them and saw that the copygb output ends at record
293.
>> >> # Copied over the list of records and removed the line for PEVAP
>> >> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
>> >>
>> >> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
>> >> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list
>> >>
>> >> # Run the subsetted file through copygb to make sure it
processes all
>> the
>> >> other records
>> >> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
>> >>
>> >> # Use wgrib to make sure that the output has all 348 (= 349 - 1)
of the
>> >> expected records
>> >> wgrib gribbyUPPV21_subset_221 | wc -l
>> >>
>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>
>> >> So it is definitely the PEVAP record that's causing the problem.
>>  You're
>> >> right, you could modify the wrf_cntrl.parm file to skip this
record
>> from
>> >> being output by UPP.  I believe that PEVAP stands for
>> >> "potential evaporation".  So I'd suggest modifying
wrf_cntrl.parm to
>> use
>> >> the following line:
>> >>
>> >>    (ACC POT EVAPORATION ) SCAL=( 4.0)
>> >>    L=(00000 00000 00000 00000 00000 00000 00000 00000 00000
00000 00000
>> >> 00000 00000 00000)
>> >>
>> >> Changing the 1 that was there to a 0 should disable it's output.
>> >>
>> >> Hope that helps.
>> >>
>> >> Thanks,
>> >> John
>> >>
>> >> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
>> >>>
>> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>> >>>
>> >>> Hi John,
>> >>>
>> >>> I uploaded three files. One is grib file produced from wrfout
by
>> UPPV2.1
>> >>> (gribbyuppv21), another is    regridded grib file by copygb.exe
>> >>> (gribbyuppv21_copygb_221), the third file is parm file used to
control
>> >>> convert wrfout to grib file by UPPV2.1.
>> >>>
>> >>> I read your previous online post which was related to my
question. You
>> >>> suggested change parm file not to output problem-making
variables
>> >> (fields).
>> >>> The question is I don't know which variables cause the problem.
Hope
>> you
>> >>> can help me.
>> >>>
>> >>> Thank you!
>> >>>
>> >>> Jiang
>> >>>
>> >>>
>> >>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
>> >>> met_help at ucar.edu> wrote:
>> >>>
>> >>>> Jiang,
>> >>>>
>> >>>> Yes, I suspect that there's a record that's causing copygb to
abort
>> and
>> >>>> give you an incomplete file.  Please post your data to our
anonymous
>> ftp
>> >>>> site following these instructions:
>> >>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>> >>>>
>> >>>> I'll take a look and will hopefully be able to provide you
with a
>> >>>> work-around.  Ultimately, it'd be better if we were able to
update
>> >> copygb
>> >>>> to avoid the floating point exception.  But realistically,
>> >>>> it'll probably be easier to just avoid processing the record
that's
>> >>>> causing it.
>> >>>>
>> >>>> Thanks,
>> >>>> John Halley Gotway
>> >>>> met_help at ucar.edu
>> >>>>
>> >>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>> >>>>>
>> >>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
>> >>>>> Transaction: Ticket created by jiang at gina.alaska.edu
>> >>>>>           Queue: met_help
>> >>>>>         Subject: question about using copygb.exe
>> >>>>>           Owner: Nobody
>> >>>>>      Requestors: jiang at gina.alaska.edu
>> >>>>>          Status: new
>> >>>>>     Ticket <URL:
>> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>> >>>>>
>> >>>>>
>> >>>>> Hi CS,
>> >>>>>
>> >>>>> I would like to use NARR data and my WRF output to do
grid_stat.
>> >>>>>
>> >>>>> MY model output is in polar projection and domain is Alaska
region.
>> I
>> >>>>> convert the WRF output  into grib by UPPV2.1,  then I use
>> >>>>>
>> >>>>> copygb.exe -xg221 ingribfile outgribfile
>> >>>>>
>> >>>>> It can complete partial record conversion. ingribfile have
349
>> records,
>> >>>>> outgribfile only include 294 records,  and it shows the
error:
>> Floating
>> >>>>> point exception.
>> >>>>>
>> >>>>> Can you tell me how I can overcome the problem. I want to
eliminate
>> >> some
>> >>>>> fields that cause problem, but I don't know what fields have
>> problem in
>> >>>>> ingribfile.
>> >>>>>
>> >>>>> I can upload these two files for you to take a look at the
problem.
>> >>>>>
>> >>>>>
>> >>>>> Thank you very much in advance.
>> >>>>>
>> >>>>> Jiang
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> --
> **********************************************************
> Jiang Zhu, Ph.D.
> Geographic Information Network of Alaska
> University of Alaska Fairbanks
> Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
> ***********************************************************
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #63081] question about using copygb.exe
From: John Halley Gotway
Time: Mon Sep 23 11:32:11 2013

Jiang,

You ask a very good question.  There is no hard and fast rule on
whether you should regrid your forecast to the observation domain or
vice-versa.  Here in the DTC, we've done it both ways in the past
for different reasons.  When you interpolate data from it's native
domain to some other domain, you're introducing some error in the
interpolation process.  Generally speaking, it's probably better to
introduce that error in the forecast field than the observation field.
And when you interpolate data from a more coarse domain to a finer
domain, the interpolation process is, in some ways,
"inventing" data.  For example, if you regridded from the 32km grid to
the 18km grid, you'd be adding in many grid points that didn't exist
in the native domain.

For these reasons, I'd suggest that you keep doing what you've been
doing: regridding the 18km forecast data to the 32km observation
domain before running them through Grid-Stat.  I think that's a
very reasonable approach.  Doing it the other way wouldn't be wrong...
there would just be more issues with it.

As for what interpolation method to use... in the DTC we use the
default options from copygb when interpolating.  However, when
interpolating accumulated precipitation, we use the budget (-i3)
interpolation option.  That does a better job preserving the total
accumulation amount during the interpolation process.

Hope that helps.

Thanks,
John

On 09/20/2013 02:16 PM, Jiang Zhu via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>
> Hi John,
>
> I got another general questions to ask your advice. When I use MET
> grid-stat tool to compare my model run (with Polar stero projection,
18 km
> resolution) with NARR (with G221 projection grid, lambert conf, 32
km
> resolution),  should I convert NARR data to polar steoro or vise
versa? and
> what interpolation method should I use?
>
> Thank you for your advice!
>
> Jiang
>
>
> On Thu, Sep 19, 2013 at 3:54 PM, Jiang Zhu <jiang at gina.alaska.edu>
wrote:
>
>> Hi John,
>>
>> You are such a great helper! Actually, I will use poly files to
mask to
>> evaluate my model in several areas in Alaska.
>>
>> Thank you very much!
>>
>> Jiang
>>
>>
>>
>>
>> On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>
>>> Jiang,
>>>
>>> I used the plot_data_plane tool to visualize your data.  I plotted
2-m
>>> temperature:
>>>      METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
>>> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
>>>
>>> I converted the resulting postscript file to a png, and it is
attached.
>>>   Looks like we've got a bit of an issue in plotting the map data,
but other
>>> than that, the data looks good.  So this data is on
>>> grid 221 but only contains valid data over Alaska.
>>>
>>> Since your forecast and observation data are on the same grid, you
can
>>> pass them directly to Grid-Stat.  Grid-Stat will only compute
statistics
>>> where the forecast and observation values are both
>>> valid.  So the stats will only be computed over the Alaska region.
You
>>> do not need to specify a masking region.
>>>
>>> However, if Grid-Stat runs slowly, providing a masking region
could speed
>>> it up.  For example, if you choose multiple smoothing methods
>>> (interp.type.method and interp.type.width), computing those over
>>> the entire observation field could be slow.  But I'd say, just try
>>> running without a mask and use the "FULL" domain.  If it runs fast
enough,
>>> I think you're fine.
>>>
>>> Thanks,
>>> John
>>>
>>> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>
>>>> Hi John,
>>>>
>>>> Thank you very much. I delete the line you suggested and re do
it, it
>>>> works! In fact, Since I only uses some variables to compare with
NARR
>>> data,
>>>> I delete many variables in wrf_control file. It is a good way to
work
>>>> raound the problem.
>>>>
>>>> I got another question: I copygb grib-ormatted wrfout file into
G221 in
>>>> order to use grid-stat tool to compare with NARR data (G221). The
>>> domain of
>>>> my WRF is alaska region, but the NARR is whole north america, do
I need
>>> set
>>>> mask in the configuration file for doing grid-stat? If yes, how
do I set
>>>> the mask? Can I just set rectangular area with lon and lat?
>>>>
>>>> Thank you very much,
>>>>
>>>> Jiang
>>>>
>>>>
>>>> On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> Jiang,
>>>>>
>>>>> The problem is being caused by record number 294 for the GRIB
code
>>> PEVAP.
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>> Here's what I did to test this...
>>>>>
>>>>> # Use wgrib to list records in the two GRIB files you sent:
>>>>> wgrib gribbyUPPV21 > gribbyUPPV21.inv
>>>>> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
>>>>>
>>>>> # Compared them and saw that the copygb output ends at record
293.
>>>>> # Copied over the list of records and removed the line for PEVAP
>>>>> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
>>>>>
>>>>> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
>>>>> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 < record_list
>>>>>
>>>>> # Run the subsetted file through copygb to make sure it
processes all
>>> the
>>>>> other records
>>>>> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
>>>>>
>>>>> # Use wgrib to make sure that the output has all 348 (= 349 - 1)
of the
>>>>> expected records
>>>>> wgrib gribbyUPPV21_subset_221 | wc -l
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>> So it is definitely the PEVAP record that's causing the problem.
>>>   You're
>>>>> right, you could modify the wrf_cntrl.parm file to skip this
record
>>> from
>>>>> being output by UPP.  I believe that PEVAP stands for
>>>>> "potential evaporation".  So I'd suggest modifying
wrf_cntrl.parm to
>>> use
>>>>> the following line:
>>>>>
>>>>>     (ACC POT EVAPORATION ) SCAL=( 4.0)
>>>>>     L=(00000 00000 00000 00000 00000 00000 00000 00000 00000
00000 00000
>>>>> 00000 00000 00000)
>>>>>
>>>>> Changing the 1 that was there to a 0 should disable it's output.
>>>>>
>>>>> Hope that helps.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> I uploaded three files. One is grib file produced from wrfout
by
>>> UPPV2.1
>>>>>> (gribbyuppv21), another is    regridded grib file by copygb.exe
>>>>>> (gribbyuppv21_copygb_221), the third file is parm file used to
control
>>>>>> convert wrfout to grib file by UPPV2.1.
>>>>>>
>>>>>> I read your previous online post which was related to my
question. You
>>>>>> suggested change parm file not to output problem-making
variables
>>>>> (fields).
>>>>>> The question is I don't know which variables cause the problem.
Hope
>>> you
>>>>>> can help me.
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Jiang
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
>>>>>> met_help at ucar.edu> wrote:
>>>>>>
>>>>>>> Jiang,
>>>>>>>
>>>>>>> Yes, I suspect that there's a record that's causing copygb to
abort
>>> and
>>>>>>> give you an incomplete file.  Please post your data to our
anonymous
>>> ftp
>>>>>>> site following these instructions:
>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>
>>>>>>> I'll take a look and will hopefully be able to provide you
with a
>>>>>>> work-around.  Ultimately, it'd be better if we were able to
update
>>>>> copygb
>>>>>>> to avoid the floating point exception.  But realistically,
>>>>>>> it'll probably be easier to just avoid processing the record
that's
>>>>>>> causing it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John Halley Gotway
>>>>>>> met_help at ucar.edu
>>>>>>>
>>>>>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>>>>>>>>
>>>>>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
>>>>>>>> Transaction: Ticket created by jiang at gina.alaska.edu
>>>>>>>>            Queue: met_help
>>>>>>>>          Subject: question about using copygb.exe
>>>>>>>>            Owner: Nobody
>>>>>>>>       Requestors: jiang at gina.alaska.edu
>>>>>>>>           Status: new
>>>>>>>>      Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi CS,
>>>>>>>>
>>>>>>>> I would like to use NARR data and my WRF output to do
grid_stat.
>>>>>>>>
>>>>>>>> MY model output is in polar projection and domain is Alaska
region.
>>> I
>>>>>>>> convert the WRF output  into grib by UPPV2.1,  then I use
>>>>>>>>
>>>>>>>> copygb.exe -xg221 ingribfile outgribfile
>>>>>>>>
>>>>>>>> It can complete partial record conversion. ingribfile have
349
>>> records,
>>>>>>>> outgribfile only include 294 records,  and it shows the
error:
>>> Floating
>>>>>>>> point exception.
>>>>>>>>
>>>>>>>> Can you tell me how I can overcome the problem. I want to
eliminate
>>>>> some
>>>>>>>> fields that cause problem, but I don't know what fields have
>>> problem in
>>>>>>>> ingribfile.
>>>>>>>>
>>>>>>>> I can upload these two files for you to take a look at the
problem.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you very much in advance.
>>>>>>>>
>>>>>>>> Jiang
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> **********************************************************
>> Jiang Zhu, Ph.D.
>> Geographic Information Network of Alaska
>> University of Alaska Fairbanks
>> Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
>> ***********************************************************
>>
>
>
>

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Mon Sep 23 13:23:03 2013

Hi John,

Thank you very much.  I will follow your advice. I got another twp
questions.
1. The goal we want to compare my model out with NARR is that we want
to
evaluate how data assimilation improve the forecast of clouds. We want
to
use RH as a agency to do this job. RH is reported in wrfout as many
levels.
but it is reported three levels in NARR. THis makes us difficult to
compare
them level by level. How can I convert TMP, PRESS, and Specific
humidity at
all levels in NARR to RH in all levels. I mean do you have code to do
this
job?

2. I found I can not use P850-750 to define the layer to compare
variable
such as Temperature in grid-stat tool. Can grid-stat tool compare
temperature at a layer not just a level?

Thank you very much!

Jiang

On Mon, Sep 23, 2013 at 9:32 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jiang,
>
> You ask a very good question.  There is no hard and fast rule on
whether
> you should regrid your forecast to the observation domain or vice-
versa.
>  Here in the DTC, we've done it both ways in the past
> for different reasons.  When you interpolate data from it's native
domain
> to some other domain, you're introducing some error in the
interpolation
> process.  Generally speaking, it's probably better to
> introduce that error in the forecast field than the observation
field.
>  And when you interpolate data from a more coarse domain to a finer
domain,
> the interpolation process is, in some ways,
> "inventing" data.  For example, if you regridded from the 32km grid
to the
> 18km grid, you'd be adding in many grid points that didn't exist in
the
> native domain.
>
> For these reasons, I'd suggest that you keep doing what you've been
doing:
> regridding the 18km forecast data to the 32km observation domain
before
> running them through Grid-Stat.  I think that's a
> very reasonable approach.  Doing it the other way wouldn't be
wrong...
> there would just be more issues with it.
>
> As for what interpolation method to use... in the DTC we use the
default
> options from copygb when interpolating.  However, when interpolating
> accumulated precipitation, we use the budget (-i3)
> interpolation option.  That does a better job preserving the total
> accumulation amount during the interpolation process.
>
> Hope that helps.
>
> Thanks,
> John
>
>
> On 09/20/2013 02:16 PM, Jiang Zhu via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >
> > Hi John,
> >
> > I got another general questions to ask your advice. When I use MET
> > grid-stat tool to compare my model run (with Polar stero
projection, 18
> km
> > resolution) with NARR (with G221 projection grid, lambert conf, 32
km
> > resolution),  should I convert NARR data to polar steoro or vise
versa?
> and
> > what interpolation method should I use?
> >
> > Thank you for your advice!
> >
> > Jiang
> >
> >
> > On Thu, Sep 19, 2013 at 3:54 PM, Jiang Zhu <jiang at gina.alaska.edu>
> wrote:
> >
> >> Hi John,
> >>
> >> You are such a great helper! Actually, I will use poly files to
mask to
> >> evaluate my model in several areas in Alaska.
> >>
> >> Thank you very much!
> >>
> >> Jiang
> >>
> >>
> >>
> >>
> >> On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >>> Jiang,
> >>>
> >>> I used the plot_data_plane tool to visualize your data.  I
plotted 2-m
> >>> temperature:
> >>>      METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
> >>> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
> >>>
> >>> I converted the resulting postscript file to a png, and it is
attached.
> >>>   Looks like we've got a bit of an issue in plotting the map
data, but
> other
> >>> than that, the data looks good.  So this data is on
> >>> grid 221 but only contains valid data over Alaska.
> >>>
> >>> Since your forecast and observation data are on the same grid,
you can
> >>> pass them directly to Grid-Stat.  Grid-Stat will only compute
> statistics
> >>> where the forecast and observation values are both
> >>> valid.  So the stats will only be computed over the Alaska
region.  You
> >>> do not need to specify a masking region.
> >>>
> >>> However, if Grid-Stat runs slowly, providing a masking region
could
> speed
> >>> it up.  For example, if you choose multiple smoothing methods
> >>> (interp.type.method and interp.type.width), computing those over
> >>> the entire observation field could be slow.  But I'd say, just
try
> >>> running without a mask and use the "FULL" domain.  If it runs
fast
> enough,
> >>> I think you're fine.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Thank you very much. I delete the line you suggested and re do
it, it
> >>>> works! In fact, Since I only uses some variables to compare
with NARR
> >>> data,
> >>>> I delete many variables in wrf_control file. It is a good way
to work
> >>>> raound the problem.
> >>>>
> >>>> I got another question: I copygb grib-ormatted wrfout file into
G221
> in
> >>>> order to use grid-stat tool to compare with NARR data (G221).
The
> >>> domain of
> >>>> my WRF is alaska region, but the NARR is whole north america,
do I
> need
> >>> set
> >>>> mask in the configuration file for doing grid-stat? If yes, how
do I
> set
> >>>> the mask? Can I just set rectangular area with lon and lat?
> >>>>
> >>>> Thank you very much,
> >>>>
> >>>> Jiang
> >>>>
> >>>>
> >>>> On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
> >>>> met_help at ucar.edu> wrote:
> >>>>
> >>>>> Jiang,
> >>>>>
> >>>>> The problem is being caused by record number 294 for the GRIB
code
> >>> PEVAP.
> >>>>>
> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>
> >>>>> Here's what I did to test this...
> >>>>>
> >>>>> # Use wgrib to list records in the two GRIB files you sent:
> >>>>> wgrib gribbyUPPV21 > gribbyUPPV21.inv
> >>>>> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
> >>>>>
> >>>>> # Compared them and saw that the copygb output ends at record
293.
> >>>>> # Copied over the list of records and removed the line for
PEVAP
> >>>>> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
> >>>>>
> >>>>> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
> >>>>> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 <
record_list
> >>>>>
> >>>>> # Run the subsetted file through copygb to make sure it
processes all
> >>> the
> >>>>> other records
> >>>>> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
> >>>>>
> >>>>> # Use wgrib to make sure that the output has all 348 (= 349 -
1) of
> the
> >>>>> expected records
> >>>>> wgrib gribbyUPPV21_subset_221 | wc -l
> >>>>>
> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>
> >>>>> So it is definitely the PEVAP record that's causing the
problem.
> >>>   You're
> >>>>> right, you could modify the wrf_cntrl.parm file to skip this
record
> >>> from
> >>>>> being output by UPP.  I believe that PEVAP stands for
> >>>>> "potential evaporation".  So I'd suggest modifying
wrf_cntrl.parm to
> >>> use
> >>>>> the following line:
> >>>>>
> >>>>>     (ACC POT EVAPORATION ) SCAL=( 4.0)
> >>>>>     L=(00000 00000 00000 00000 00000 00000 00000 00000 00000
00000
> 00000
> >>>>> 00000 00000 00000)
> >>>>>
> >>>>> Changing the 1 that was there to a 0 should disable it's
output.
> >>>>>
> >>>>> Hope that helps.
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> I uploaded three files. One is grib file produced from wrfout
by
> >>> UPPV2.1
> >>>>>> (gribbyuppv21), another is    regridded grib file by
copygb.exe
> >>>>>> (gribbyuppv21_copygb_221), the third file is parm file used
to
> control
> >>>>>> convert wrfout to grib file by UPPV2.1.
> >>>>>>
> >>>>>> I read your previous online post which was related to my
question.
> You
> >>>>>> suggested change parm file not to output problem-making
variables
> >>>>> (fields).
> >>>>>> The question is I don't know which variables cause the
problem. Hope
> >>> you
> >>>>>> can help me.
> >>>>>>
> >>>>>> Thank you!
> >>>>>>
> >>>>>> Jiang
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
> >>>>>> met_help at ucar.edu> wrote:
> >>>>>>
> >>>>>>> Jiang,
> >>>>>>>
> >>>>>>> Yes, I suspect that there's a record that's causing copygb
to abort
> >>> and
> >>>>>>> give you an incomplete file.  Please post your data to our
> anonymous
> >>> ftp
> >>>>>>> site following these instructions:
> >>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>>>>>>
> >>>>>>> I'll take a look and will hopefully be able to provide you
with a
> >>>>>>> work-around.  Ultimately, it'd be better if we were able to
update
> >>>>> copygb
> >>>>>>> to avoid the floating point exception.  But realistically,
> >>>>>>> it'll probably be easier to just avoid processing the record
that's
> >>>>>>> causing it.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> John Halley Gotway
> >>>>>>> met_help at ucar.edu
> >>>>>>>
> >>>>>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
> >>>>>>>>
> >>>>>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> >>>>>>>> Transaction: Ticket created by jiang at gina.alaska.edu
> >>>>>>>>            Queue: met_help
> >>>>>>>>          Subject: question about using copygb.exe
> >>>>>>>>            Owner: Nobody
> >>>>>>>>       Requestors: jiang at gina.alaska.edu
> >>>>>>>>           Status: new
> >>>>>>>>      Ticket <URL:
> >>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi CS,
> >>>>>>>>
> >>>>>>>> I would like to use NARR data and my WRF output to do
grid_stat.
> >>>>>>>>
> >>>>>>>> MY model output is in polar projection and domain is Alaska
> region.
> >>> I
> >>>>>>>> convert the WRF output  into grib by UPPV2.1,  then I use
> >>>>>>>>
> >>>>>>>> copygb.exe -xg221 ingribfile outgribfile
> >>>>>>>>
> >>>>>>>> It can complete partial record conversion. ingribfile have
349
> >>> records,
> >>>>>>>> outgribfile only include 294 records,  and it shows the
error:
> >>> Floating
> >>>>>>>> point exception.
> >>>>>>>>
> >>>>>>>> Can you tell me how I can overcome the problem. I want to
> eliminate
> >>>>> some
> >>>>>>>> fields that cause problem, but I don't know what fields
have
> >>> problem in
> >>>>>>>> ingribfile.
> >>>>>>>>
> >>>>>>>> I can upload these two files for you to take a look at the
> problem.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thank you very much in advance.
> >>>>>>>>
> >>>>>>>> Jiang
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> **********************************************************
> >> Jiang Zhu, Ph.D.
> >> Geographic Information Network of Alaska
> >> University of Alaska Fairbanks
> >> Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
> >> ***********************************************************
> >>
> >
> >
> >
>
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #63081] question about using copygb.exe
From: John Halley Gotway
Time: Mon Sep 23 13:35:35 2013

Jiang,

To answer #1, no I do not have code that will easily compute RH for
you from TMP, PRESS, and SPFH over a gridded field of data.  The PB2NC
tool does have code to derive RH from those variables for
point data.  Look at the function "convert_p_q_t_to_rh" in the file
METv4.1/src/basic/vx_util/conversions.cc.  This implements the
relative humidity derivation used by the Unified-PostProcessor (UPP).
  You could use the same algorithm to derive it, but you'll need to
write the output into a gridded data format that MET can read, like
GRIB or make it look like NetCDF output of the pcp_combine tool.

The Grid-Stat tool can be used to extract a single field of data from
the forecast and observation files and compare them.  Some GRIB
records are defined at a single pressure level, like P850, while
others are defined over a layer of data, like P850-750.  If your GRIB
file contains a record defined over a pressure layer, then yes, it can
be used directly by Grid-Stat.  But if it's really 3
separate records defined at 3 separate pressure levels, like P750,
P800, and P850, then no, Grid-Stat can't verify them all together.
Instead, you'd verify them at each level individually.

If you can't figure out how to select a record from a GRIB file for
Grid-Stat, just post the GRIB file to our anonymous ftp site and let
me know what you're trying to do.  You can post the data
following the instructions here:
    http://www.dtcenter.org/met/users/support/met_help.php#ftp

Thanks,
John

On 09/23/2013 01:23 PM, Jiang Zhu via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>
> Hi John,
>
> Thank you very much.  I will follow your advice. I got another twp
> questions.
> 1. The goal we want to compare my model out with NARR is that we
want to
> evaluate how data assimilation improve the forecast of clouds. We
want to
> use RH as a agency to do this job. RH is reported in wrfout as many
levels.
> but it is reported three levels in NARR. THis makes us difficult to
compare
> them level by level. How can I convert TMP, PRESS, and Specific
humidity at
> all levels in NARR to RH in all levels. I mean do you have code to
do this
> job?
>
> 2. I found I can not use P850-750 to define the layer to compare
variable
> such as Temperature in grid-stat tool. Can grid-stat tool compare
> temperature at a layer not just a level?
>
> Thank you very much!
>
> Jiang
>
>
>
>
> On Mon, Sep 23, 2013 at 9:32 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jiang,
>>
>> You ask a very good question.  There is no hard and fast rule on
whether
>> you should regrid your forecast to the observation domain or vice-
versa.
>>   Here in the DTC, we've done it both ways in the past
>> for different reasons.  When you interpolate data from it's native
domain
>> to some other domain, you're introducing some error in the
interpolation
>> process.  Generally speaking, it's probably better to
>> introduce that error in the forecast field than the observation
field.
>>   And when you interpolate data from a more coarse domain to a
finer domain,
>> the interpolation process is, in some ways,
>> "inventing" data.  For example, if you regridded from the 32km grid
to the
>> 18km grid, you'd be adding in many grid points that didn't exist in
the
>> native domain.
>>
>> For these reasons, I'd suggest that you keep doing what you've been
doing:
>> regridding the 18km forecast data to the 32km observation domain
before
>> running them through Grid-Stat.  I think that's a
>> very reasonable approach.  Doing it the other way wouldn't be
wrong...
>> there would just be more issues with it.
>>
>> As for what interpolation method to use... in the DTC we use the
default
>> options from copygb when interpolating.  However, when
interpolating
>> accumulated precipitation, we use the budget (-i3)
>> interpolation option.  That does a better job preserving the total
>> accumulation amount during the interpolation process.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>>
>> On 09/20/2013 02:16 PM, Jiang Zhu via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>
>>> Hi John,
>>>
>>> I got another general questions to ask your advice. When I use MET
>>> grid-stat tool to compare my model run (with Polar stero
projection, 18
>> km
>>> resolution) with NARR (with G221 projection grid, lambert conf, 32
km
>>> resolution),  should I convert NARR data to polar steoro or vise
versa?
>> and
>>> what interpolation method should I use?
>>>
>>> Thank you for your advice!
>>>
>>> Jiang
>>>
>>>
>>> On Thu, Sep 19, 2013 at 3:54 PM, Jiang Zhu <jiang at gina.alaska.edu>
>> wrote:
>>>
>>>> Hi John,
>>>>
>>>> You are such a great helper! Actually, I will use poly files to
mask to
>>>> evaluate my model in several areas in Alaska.
>>>>
>>>> Thank you very much!
>>>>
>>>> Jiang
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> Jiang,
>>>>>
>>>>> I used the plot_data_plane tool to visualize your data.  I
plotted 2-m
>>>>> temperature:
>>>>>       METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
>>>>> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
>>>>>
>>>>> I converted the resulting postscript file to a png, and it is
attached.
>>>>>    Looks like we've got a bit of an issue in plotting the map
data, but
>> other
>>>>> than that, the data looks good.  So this data is on
>>>>> grid 221 but only contains valid data over Alaska.
>>>>>
>>>>> Since your forecast and observation data are on the same grid,
you can
>>>>> pass them directly to Grid-Stat.  Grid-Stat will only compute
>> statistics
>>>>> where the forecast and observation values are both
>>>>> valid.  So the stats will only be computed over the Alaska
region.  You
>>>>> do not need to specify a masking region.
>>>>>
>>>>> However, if Grid-Stat runs slowly, providing a masking region
could
>> speed
>>>>> it up.  For example, if you choose multiple smoothing methods
>>>>> (interp.type.method and interp.type.width), computing those over
>>>>> the entire observation field could be slow.  But I'd say, just
try
>>>>> running without a mask and use the "FULL" domain.  If it runs
fast
>> enough,
>>>>> I think you're fine.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> Thank you very much. I delete the line you suggested and re do
it, it
>>>>>> works! In fact, Since I only uses some variables to compare
with NARR
>>>>> data,
>>>>>> I delete many variables in wrf_control file. It is a good way
to work
>>>>>> raound the problem.
>>>>>>
>>>>>> I got another question: I copygb grib-ormatted wrfout file into
G221
>> in
>>>>>> order to use grid-stat tool to compare with NARR data (G221).
The
>>>>> domain of
>>>>>> my WRF is alaska region, but the NARR is whole north america,
do I
>> need
>>>>> set
>>>>>> mask in the configuration file for doing grid-stat? If yes, how
do I
>> set
>>>>>> the mask? Can I just set rectangular area with lon and lat?
>>>>>>
>>>>>> Thank you very much,
>>>>>>
>>>>>> Jiang
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
>>>>>> met_help at ucar.edu> wrote:
>>>>>>
>>>>>>> Jiang,
>>>>>>>
>>>>>>> The problem is being caused by record number 294 for the GRIB
code
>>>>> PEVAP.
>>>>>>>
>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>
>>>>>>> Here's what I did to test this...
>>>>>>>
>>>>>>> # Use wgrib to list records in the two GRIB files you sent:
>>>>>>> wgrib gribbyUPPV21 > gribbyUPPV21.inv
>>>>>>> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
>>>>>>>
>>>>>>> # Compared them and saw that the copygb output ends at record
293.
>>>>>>> # Copied over the list of records and removed the line for
PEVAP
>>>>>>> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
>>>>>>>
>>>>>>> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
>>>>>>> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 <
record_list
>>>>>>>
>>>>>>> # Run the subsetted file through copygb to make sure it
processes all
>>>>> the
>>>>>>> other records
>>>>>>> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
>>>>>>>
>>>>>>> # Use wgrib to make sure that the output has all 348 (= 349 -
1) of
>> the
>>>>>>> expected records
>>>>>>> wgrib gribbyUPPV21_subset_221 | wc -l
>>>>>>>
>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>
>>>>>>> So it is definitely the PEVAP record that's causing the
problem.
>>>>>    You're
>>>>>>> right, you could modify the wrf_cntrl.parm file to skip this
record
>>>>> from
>>>>>>> being output by UPP.  I believe that PEVAP stands for
>>>>>>> "potential evaporation".  So I'd suggest modifying
wrf_cntrl.parm to
>>>>> use
>>>>>>> the following line:
>>>>>>>
>>>>>>>      (ACC POT EVAPORATION ) SCAL=( 4.0)
>>>>>>>      L=(00000 00000 00000 00000 00000 00000 00000 00000 00000
00000
>> 00000
>>>>>>> 00000 00000 00000)
>>>>>>>
>>>>>>> Changing the 1 that was there to a 0 should disable it's
output.
>>>>>>>
>>>>>>> Hope that helps.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
>>>>>>>>
>>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081
>
>>>>>>>>
>>>>>>>> Hi John,
>>>>>>>>
>>>>>>>> I uploaded three files. One is grib file produced from wrfout
by
>>>>> UPPV2.1
>>>>>>>> (gribbyuppv21), another is    regridded grib file by
copygb.exe
>>>>>>>> (gribbyuppv21_copygb_221), the third file is parm file used
to
>> control
>>>>>>>> convert wrfout to grib file by UPPV2.1.
>>>>>>>>
>>>>>>>> I read your previous online post which was related to my
question.
>> You
>>>>>>>> suggested change parm file not to output problem-making
variables
>>>>>>> (fields).
>>>>>>>> The question is I don't know which variables cause the
problem. Hope
>>>>> you
>>>>>>>> can help me.
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>>
>>>>>>>> Jiang
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT <
>>>>>>>> met_help at ucar.edu> wrote:
>>>>>>>>
>>>>>>>>> Jiang,
>>>>>>>>>
>>>>>>>>> Yes, I suspect that there's a record that's causing copygb
to abort
>>>>> and
>>>>>>>>> give you an incomplete file.  Please post your data to our
>> anonymous
>>>>> ftp
>>>>>>>>> site following these instructions:
>>>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>>>
>>>>>>>>> I'll take a look and will hopefully be able to provide you
with a
>>>>>>>>> work-around.  Ultimately, it'd be better if we were able to
update
>>>>>>> copygb
>>>>>>>>> to avoid the floating point exception.  But realistically,
>>>>>>>>> it'll probably be easier to just avoid processing the record
that's
>>>>>>>>> causing it.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John Halley Gotway
>>>>>>>>> met_help at ucar.edu
>>>>>>>>>
>>>>>>>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
>>>>>>>>>>
>>>>>>>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
>>>>>>>>>> Transaction: Ticket created by jiang at gina.alaska.edu
>>>>>>>>>>             Queue: met_help
>>>>>>>>>>           Subject: question about using copygb.exe
>>>>>>>>>>             Owner: Nobody
>>>>>>>>>>        Requestors: jiang at gina.alaska.edu
>>>>>>>>>>            Status: new
>>>>>>>>>>       Ticket <URL:
>>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi CS,
>>>>>>>>>>
>>>>>>>>>> I would like to use NARR data and my WRF output to do
grid_stat.
>>>>>>>>>>
>>>>>>>>>> MY model output is in polar projection and domain is Alaska
>> region.
>>>>> I
>>>>>>>>>> convert the WRF output  into grib by UPPV2.1,  then I use
>>>>>>>>>>
>>>>>>>>>> copygb.exe -xg221 ingribfile outgribfile
>>>>>>>>>>
>>>>>>>>>> It can complete partial record conversion. ingribfile have
349
>>>>> records,
>>>>>>>>>> outgribfile only include 294 records,  and it shows the
error:
>>>>> Floating
>>>>>>>>>> point exception.
>>>>>>>>>>
>>>>>>>>>> Can you tell me how I can overcome the problem. I want to
>> eliminate
>>>>>>> some
>>>>>>>>>> fields that cause problem, but I don't know what fields
have
>>>>> problem in
>>>>>>>>>> ingribfile.
>>>>>>>>>>
>>>>>>>>>> I can upload these two files for you to take a look at the
>> problem.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you very much in advance.
>>>>>>>>>>
>>>>>>>>>> Jiang
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> **********************************************************
>>>> Jiang Zhu, Ph.D.
>>>> Geographic Information Network of Alaska
>>>> University of Alaska Fairbanks
>>>> Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
>>>> ***********************************************************
>>>>
>>>
>>>
>>>
>>
>>
>
>

------------------------------------------------
Subject: question about using copygb.exe
From: Jiang Zhu
Time: Mon Sep 23 16:30:26 2013

Hi John,

Thank you very much. I may use the convert code to do what I want to
do.
Your advice is very constructive.

I appreciate your help.

Jiang

On Mon, Sep 23, 2013 at 11:35 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:

> Jiang,
>
> To answer #1, no I do not have code that will easily compute RH for
you
> from TMP, PRESS, and SPFH over a gridded field of data.  The PB2NC
tool
> does have code to derive RH from those variables for
> point data.  Look at the function "convert_p_q_t_to_rh" in the file
> METv4.1/src/basic/vx_util/conversions.cc.  This implements the
relative
> humidity derivation used by the Unified-PostProcessor (UPP).
>   You could use the same algorithm to derive it, but you'll need to
write
> the output into a gridded data format that MET can read, like GRIB
or make
> it look like NetCDF output of the pcp_combine tool.
>
> The Grid-Stat tool can be used to extract a single field of data
from the
> forecast and observation files and compare them.  Some GRIB records
are
> defined at a single pressure level, like P850, while
> others are defined over a layer of data, like P850-750.  If your
GRIB file
> contains a record defined over a pressure layer, then yes, it can be
used
> directly by Grid-Stat.  But if it's really 3
> separate records defined at 3 separate pressure levels, like P750,
P800,
> and P850, then no, Grid-Stat can't verify them all together.
Instead,
> you'd verify them at each level individually.
>
> If you can't figure out how to select a record from a GRIB file for
> Grid-Stat, just post the GRIB file to our anonymous ftp site and let
me
> know what you're trying to do.  You can post the data
> following the instructions here:
>     http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Thanks,
> John
>
>
>
> On 09/23/2013 01:23 PM, Jiang Zhu via RT wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >
> > Hi John,
> >
> > Thank you very much.  I will follow your advice. I got another twp
> > questions.
> > 1. The goal we want to compare my model out with NARR is that we
want to
> > evaluate how data assimilation improve the forecast of clouds. We
want to
> > use RH as a agency to do this job. RH is reported in wrfout as
many
> levels.
> > but it is reported three levels in NARR. THis makes us difficult
to
> compare
> > them level by level. How can I convert TMP, PRESS, and Specific
humidity
> at
> > all levels in NARR to RH in all levels. I mean do you have code to
do
> this
> > job?
> >
> > 2. I found I can not use P850-750 to define the layer to compare
variable
> > such as Temperature in grid-stat tool. Can grid-stat tool compare
> > temperature at a layer not just a level?
> >
> > Thank you very much!
> >
> > Jiang
> >
> >
> >
> >
> > On Mon, Sep 23, 2013 at 9:32 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jiang,
> >>
> >> You ask a very good question.  There is no hard and fast rule on
whether
> >> you should regrid your forecast to the observation domain or
vice-versa.
> >>   Here in the DTC, we've done it both ways in the past
> >> for different reasons.  When you interpolate data from it's
native
> domain
> >> to some other domain, you're introducing some error in the
interpolation
> >> process.  Generally speaking, it's probably better to
> >> introduce that error in the forecast field than the observation
field.
> >>   And when you interpolate data from a more coarse domain to a
finer
> domain,
> >> the interpolation process is, in some ways,
> >> "inventing" data.  For example, if you regridded from the 32km
grid to
> the
> >> 18km grid, you'd be adding in many grid points that didn't exist
in the
> >> native domain.
> >>
> >> For these reasons, I'd suggest that you keep doing what you've
been
> doing:
> >> regridding the 18km forecast data to the 32km observation domain
before
> >> running them through Grid-Stat.  I think that's a
> >> very reasonable approach.  Doing it the other way wouldn't be
wrong...
> >> there would just be more issues with it.
> >>
> >> As for what interpolation method to use... in the DTC we use the
default
> >> options from copygb when interpolating.  However, when
interpolating
> >> accumulated precipitation, we use the budget (-i3)
> >> interpolation option.  That does a better job preserving the
total
> >> accumulation amount during the interpolation process.
> >>
> >> Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> On 09/20/2013 02:16 PM, Jiang Zhu via RT wrote:
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>
> >>> Hi John,
> >>>
> >>> I got another general questions to ask your advice. When I use
MET
> >>> grid-stat tool to compare my model run (with Polar stero
projection, 18
> >> km
> >>> resolution) with NARR (with G221 projection grid, lambert conf,
32 km
> >>> resolution),  should I convert NARR data to polar steoro or vise
versa?
> >> and
> >>> what interpolation method should I use?
> >>>
> >>> Thank you for your advice!
> >>>
> >>> Jiang
> >>>
> >>>
> >>> On Thu, Sep 19, 2013 at 3:54 PM, Jiang Zhu
<jiang at gina.alaska.edu>
> >> wrote:
> >>>
> >>>> Hi John,
> >>>>
> >>>> You are such a great helper! Actually, I will use poly files to
mask
> to
> >>>> evaluate my model in several areas in Alaska.
> >>>>
> >>>> Thank you very much!
> >>>>
> >>>> Jiang
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Sep 19, 2013 at 2:48 PM, John Halley Gotway via RT <
> >>>> met_help at ucar.edu> wrote:
> >>>>
> >>>>> Jiang,
> >>>>>
> >>>>> I used the plot_data_plane tool to visualize your data.  I
plotted
> 2-m
> >>>>> temperature:
> >>>>>       METv4.1/bin/plot_data_plane gribbyUPPV21_copygb_221
> >>>>> gribbyUPPV21_TMP_Z2.ps 'name="TMP"; level="Z2";'
> >>>>>
> >>>>> I converted the resulting postscript file to a png, and it is
> attached.
> >>>>>    Looks like we've got a bit of an issue in plotting the map
data,
> but
> >> other
> >>>>> than that, the data looks good.  So this data is on
> >>>>> grid 221 but only contains valid data over Alaska.
> >>>>>
> >>>>> Since your forecast and observation data are on the same grid,
you
> can
> >>>>> pass them directly to Grid-Stat.  Grid-Stat will only compute
> >> statistics
> >>>>> where the forecast and observation values are both
> >>>>> valid.  So the stats will only be computed over the Alaska
region.
>  You
> >>>>> do not need to specify a masking region.
> >>>>>
> >>>>> However, if Grid-Stat runs slowly, providing a masking region
could
> >> speed
> >>>>> it up.  For example, if you choose multiple smoothing methods
> >>>>> (interp.type.method and interp.type.width), computing those
over
> >>>>> the entire observation field could be slow.  But I'd say, just
try
> >>>>> running without a mask and use the "FULL" domain.  If it runs
fast
> >> enough,
> >>>>> I think you're fine.
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>> On 09/19/2013 04:10 PM, Jiang Zhu via RT wrote:
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081
>
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> Thank you very much. I delete the line you suggested and re
do it,
> it
> >>>>>> works! In fact, Since I only uses some variables to compare
with
> NARR
> >>>>> data,
> >>>>>> I delete many variables in wrf_control file. It is a good way
to
> work
> >>>>>> raound the problem.
> >>>>>>
> >>>>>> I got another question: I copygb grib-ormatted wrfout file
into G221
> >> in
> >>>>>> order to use grid-stat tool to compare with NARR data (G221).
The
> >>>>> domain of
> >>>>>> my WRF is alaska region, but the NARR is whole north america,
do I
> >> need
> >>>>> set
> >>>>>> mask in the configuration file for doing grid-stat? If yes,
how do I
> >> set
> >>>>>> the mask? Can I just set rectangular area with lon and lat?
> >>>>>>
> >>>>>> Thank you very much,
> >>>>>>
> >>>>>> Jiang
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Sep 19, 2013 at 1:08 PM, John Halley Gotway via RT <
> >>>>>> met_help at ucar.edu> wrote:
> >>>>>>
> >>>>>>> Jiang,
> >>>>>>>
> >>>>>>> The problem is being caused by record number 294 for the
GRIB code
> >>>>> PEVAP.
> >>>>>>>
> >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>>
> >>>>>>> Here's what I did to test this...
> >>>>>>>
> >>>>>>> # Use wgrib to list records in the two GRIB files you sent:
> >>>>>>> wgrib gribbyUPPV21 > gribbyUPPV21.inv
> >>>>>>> wgrib gribbyUPPV21_copygb_221 > gribbyUPPV21_copygb_221.inv
> >>>>>>>
> >>>>>>> # Compared them and saw that the copygb output ends at
record 293.
> >>>>>>> # Copied over the list of records and removed the line for
PEVAP
> >>>>>>> cat gribbyUPPV21.inv | egrep -v "PEVAP" > record_list
> >>>>>>>
> >>>>>>> # Run wgrib to subset the GRIB file to get rid of the PEVAP
record
> >>>>>>> wgrib -i -o gribbyUPPV21_subset -grib gribbyUPPV21 <
record_list
> >>>>>>>
> >>>>>>> # Run the subsetted file through copygb to make sure it
processes
> all
> >>>>> the
> >>>>>>> other records
> >>>>>>> copygb -xg221 gribbyUPPV21_subset gribbyUPPV21_subset_221
> >>>>>>>
> >>>>>>> # Use wgrib to make sure that the output has all 348 (= 349
- 1) of
> >> the
> >>>>>>> expected records
> >>>>>>> wgrib gribbyUPPV21_subset_221 | wc -l
> >>>>>>>
> >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>>
> >>>>>>> So it is definitely the PEVAP record that's causing the
problem.
> >>>>>    You're
> >>>>>>> right, you could modify the wrf_cntrl.parm file to skip this
record
> >>>>> from
> >>>>>>> being output by UPP.  I believe that PEVAP stands for
> >>>>>>> "potential evaporation".  So I'd suggest modifying
wrf_cntrl.parm
> to
> >>>>> use
> >>>>>>> the following line:
> >>>>>>>
> >>>>>>>      (ACC POT EVAPORATION ) SCAL=( 4.0)
> >>>>>>>      L=(00000 00000 00000 00000 00000 00000 00000 00000
00000 00000
> >> 00000
> >>>>>>> 00000 00000 00000)
> >>>>>>>
> >>>>>>> Changing the 1 that was there to a 0 should disable it's
output.
> >>>>>>>
> >>>>>>> Hope that helps.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> John
> >>>>>>>
> >>>>>>> On 09/19/2013 11:56 AM, Jiang Zhu via RT wrote:
> >>>>>>>>
> >>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>>>>>>
> >>>>>>>> Hi John,
> >>>>>>>>
> >>>>>>>> I uploaded three files. One is grib file produced from
wrfout by
> >>>>> UPPV2.1
> >>>>>>>> (gribbyuppv21), another is    regridded grib file by
copygb.exe
> >>>>>>>> (gribbyuppv21_copygb_221), the third file is parm file used
to
> >> control
> >>>>>>>> convert wrfout to grib file by UPPV2.1.
> >>>>>>>>
> >>>>>>>> I read your previous online post which was related to my
question.
> >> You
> >>>>>>>> suggested change parm file not to output problem-making
variables
> >>>>>>> (fields).
> >>>>>>>> The question is I don't know which variables cause the
problem.
> Hope
> >>>>> you
> >>>>>>>> can help me.
> >>>>>>>>
> >>>>>>>> Thank you!
> >>>>>>>>
> >>>>>>>> Jiang
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Sep 19, 2013 at 7:59 AM, John Halley Gotway via RT
<
> >>>>>>>> met_help at ucar.edu> wrote:
> >>>>>>>>
> >>>>>>>>> Jiang,
> >>>>>>>>>
> >>>>>>>>> Yes, I suspect that there's a record that's causing copygb
to
> abort
> >>>>> and
> >>>>>>>>> give you an incomplete file.  Please post your data to our
> >> anonymous
> >>>>> ftp
> >>>>>>>>> site following these instructions:
> >>>>>>>>>
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>>>>>>>>
> >>>>>>>>> I'll take a look and will hopefully be able to provide you
with a
> >>>>>>>>> work-around.  Ultimately, it'd be better if we were able
to
> update
> >>>>>>> copygb
> >>>>>>>>> to avoid the floating point exception.  But realistically,
> >>>>>>>>> it'll probably be easier to just avoid processing the
record
> that's
> >>>>>>>>> causing it.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> John Halley Gotway
> >>>>>>>>> met_help at ucar.edu
> >>>>>>>>>
> >>>>>>>>> On 09/18/2013 07:13 PM, Jiang Zhu via RT wrote:
> >>>>>>>>>>
> >>>>>>>>>> Wed Sep 18 19:13:47 2013: Request 63081 was acted upon.
> >>>>>>>>>> Transaction: Ticket created by jiang at gina.alaska.edu
> >>>>>>>>>>             Queue: met_help
> >>>>>>>>>>           Subject: question about using copygb.exe
> >>>>>>>>>>             Owner: Nobody
> >>>>>>>>>>        Requestors: jiang at gina.alaska.edu
> >>>>>>>>>>            Status: new
> >>>>>>>>>>       Ticket <URL:
> >>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=63081 >
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Hi CS,
> >>>>>>>>>>
> >>>>>>>>>> I would like to use NARR data and my WRF output to do
grid_stat.
> >>>>>>>>>>
> >>>>>>>>>> MY model output is in polar projection and domain is
Alaska
> >> region.
> >>>>> I
> >>>>>>>>>> convert the WRF output  into grib by UPPV2.1,  then I use
> >>>>>>>>>>
> >>>>>>>>>> copygb.exe -xg221 ingribfile outgribfile
> >>>>>>>>>>
> >>>>>>>>>> It can complete partial record conversion. ingribfile
have 349
> >>>>> records,
> >>>>>>>>>> outgribfile only include 294 records,  and it shows the
error:
> >>>>> Floating
> >>>>>>>>>> point exception.
> >>>>>>>>>>
> >>>>>>>>>> Can you tell me how I can overcome the problem. I want to
> >> eliminate
> >>>>>>> some
> >>>>>>>>>> fields that cause problem, but I don't know what fields
have
> >>>>> problem in
> >>>>>>>>>> ingribfile.
> >>>>>>>>>>
> >>>>>>>>>> I can upload these two files for you to take a look at
the
> >> problem.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thank you very much in advance.
> >>>>>>>>>>
> >>>>>>>>>> Jiang
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> **********************************************************
> >>>> Jiang Zhu, Ph.D.
> >>>> Geographic Information Network of Alaska
> >>>> University of Alaska Fairbanks
> >>>> Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
> >>>> ***********************************************************
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

--
**********************************************************
Jiang Zhu, Ph.D.
Geographic Information Network of Alaska
University of Alaska Fairbanks
Phone: 907-474-5689, EMAIL: jiang at gina.alaska.edu
***********************************************************

------------------------------------------------