[Met_help] [rt.rap.ucar.edu #46555] History for Floating error in GCPairData::add_obs call to nint
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Tue May 3 08:53:08 MDT 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I am new to MET and am running into what are probably newbie issues. As a first attempt, I’m trying to run MET for a domain over the central US using the obs dataset ds337.0 downloaded from NCAR, which is the PREPBUFR data already converted to netCDF. My WRF run is from ARW and the output has been interpolated to pressure levels with p_interp. When I run point_stat using the attached config file for a single time I keep getting errors for the line:
x = nint(obs_x);
in GCPairData::add_obs. That line then calls nint, which crashes at line 37:
a = (int) y;
of nint.cc. The specific lat/lon leading to the issue is for the case hdr_lat=-90 and hdr_lon=0, which results in obs_x=11488044980682.4. I assume that I’m getting a floating overflow in the integer conversion. I tried using a different date for comparison thinking I might have a bad obs file, but I get the same error with the same coordinates. If it matters, I am on a pretty standard Red Hat Linux system using Portland v11.3 compilers.
Do you expect that I am doing something wrong? Or, is this a bug? Given that I’ve never run MET before, I am more suspicious of user error. But I’m to the point of seeking help. Thanks for any suggestions.
-Bill
_______________________________________________
William I. Gustafson Jr., Ph.D.
Scientist
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
Pacific Northwest National Laboratory
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
http://www.researcherid.com/rid/A-7732-2008
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: John Halley Gotway
Time: Fri Apr 29 09:37:49 2011
William,
I'm not exactly sure what's going on here. I suspect that you're
right that there's some floating point issue occurring - especially
since the observation apparently occurs exactly at the south pole.
Perhaps the grid conversion math is breaking down there. I think
what would be most helpful would be for you to send me some sample
data - specifically, the data you use to run Point-Stat that
produces this error:
- Forecast file: NetCDF output of pinterp
- Observation file: NetCDF file from ds337.0
- Configuration file
You can post them to our anonymous ftp site using the following
instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
I'll run it here to try to replicate/debug the problem.
Once you've posted the data, please let me know so that I can retrieve
it.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I} wrote:
>
> Thu Apr 28 15:44:33 2011: Request 46555 was acted upon.
> Transaction: Ticket created by william.gustafson at pnl.gov
> Queue: met_help
> Subject: Floating error in GCPairData::add_obs call to nint
> Owner: Nobody
> Requestors: william.gustafson at pnl.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>
>
> Hi,
>
> I am new to MET and am running into what are probably newbie issues.
As a first attempt, I’m trying to run MET for a domain over the
central US using the obs dataset ds337.0 downloaded from NCAR, which
is the PREPBUFR data already converted to netCDF. My WRF run is from
ARW and the output has been interpolated to pressure levels with
p_interp. When I run point_stat using the attached config file for a
single time I keep getting errors for the line:
>
> x = nint(obs_x);
>
> in GCPairData::add_obs. That line then calls nint, which crashes at
line 37:
>
> a = (int) y;
>
> of nint.cc. The specific lat/lon leading to the issue is for the
case hdr_lat=-90 and hdr_lon=0, which results in
obs_x=11488044980682.4. I assume that I’m getting a floating overflow
in the integer conversion. I tried using a different date for
comparison thinking I might have a bad obs file, but I get the same
error with the same coordinates. If it matters, I am on a pretty
standard Red Hat Linux system using Portland v11.3 compilers.
>
> Do you expect that I am doing something wrong? Or, is this a bug?
Given that I’ve never run MET before, I am more suspicious of user
error. But I’m to the point of seeking help. Thanks for any
suggestions.
>
> -Bill
>
> _______________________________________________
> William I. Gustafson Jr., Ph.D.
> Scientist
>
> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
> Pacific Northwest National Laboratory
> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
> http://www.researcherid.com/rid/A-7732-2008
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: Gustafson, William I
Time: Fri Apr 29 11:20:55 2011
John,
I put the three files on the ftp site under
incoming/irap/met_help/gustafson_data. I also included a test program
showing what is causing the overflow. The test is in f90 because that
is
what I know, but I assume the problem is similar in C++. The double
float is
being assigned into a standard int. The int cannot hold the large
float
number and an overflow is triggered. If I compile the test program
with "-i8
-r8" to force long integers in addition to the double float then
everything
works fine. The sample output is in the top of the testbigint.f90 file
if
you want to look at it. I guess the big question is if the value being
sent
as the obs_x value is reasonable or not. I don't know the units being
used
so I am not sure. If the number isn't reasonable, then the overflow is
just
a symptom. If the value is OK, then the integer needs to be changed to
a
long.
To temporarily get around the problem, I turned of floating point
checks
(-Ktrap=fp) when I compiled MET yesterday afternoon. I was able to get
it to
run to completion this way, but it does this by ignoring the above
problem.
It makes me a bit nervous. :-)
-Bill
On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley Gotway}"
<met_help at ucar.edu> wrote:
> William,
>
> I'm not exactly sure what's going on here. I suspect that you're
right that
> there's some floating point issue occurring - especially since the
observation
> apparently occurs exactly at the south pole.
> Perhaps the grid conversion math is breaking down there. I think
what would
> be most helpful would be for you to send me some sample data -
specifically,
> the data you use to run Point-Stat that
> produces this error:
> - Forecast file: NetCDF output of pinterp
> - Observation file: NetCDF file from ds337.0
> - Configuration file
>
> You can post them to our anonymous ftp site using the following
instructions:
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> I'll run it here to try to replicate/debug the problem.
>
> Once you've posted the data, please let me know so that I can
retrieve it.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>
>> Thu Apr 28 15:44:33 2011: Request 46555 was acted upon.
>> Transaction: Ticket created by william.gustafson at pnl.gov
>> Queue: met_help
>> Subject: Floating error in GCPairData::add_obs call to nint
>> Owner: Nobody
>> Requestors: william.gustafson at pnl.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>
>>
>> Hi,
>>
>> I am new to MET and am running into what are probably newbie
issues. As a
>> first attempt, I¹m trying to run MET for a domain over the central
US using
>> the obs dataset ds337.0 downloaded from NCAR, which is the PREPBUFR
data
>> already converted to netCDF. My WRF run is from ARW and the output
has been
>> interpolated to pressure levels with p_interp. When I run
point_stat using
>> the attached config file for a single time I keep getting errors
for the
>> line:
>>
>> x = nint(obs_x);
>>
>> in GCPairData::add_obs. That line then calls nint, which crashes at
line 37:
>>
>> a = (int) y;
>>
>> of nint.cc. The specific lat/lon leading to the issue is for the
case
>> hdr_lat=-90 and hdr_lon=0, which results in obs_x=11488044980682.4.
I assume
>> that I¹m getting a floating overflow in the integer conversion. I
tried using
>> a different date for comparison thinking I might have a bad obs
file, but I
>> get the same error with the same coordinates. If it matters, I am
on a pretty
>> standard Red Hat Linux system using Portland v11.3 compilers.
>>
>> Do you expect that I am doing something wrong? Or, is this a bug?
Given that
>> I¹ve never run MET before, I am more suspicious of user error. But
I¹m to the
>> point of seeking help. Thanks for any suggestions.
>>
>> -Bill
>>
>> _______________________________________________
>> William I. Gustafson Jr., Ph.D.
>> Scientist
>>
>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>> Pacific Northwest National Laboratory
>> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>> http://www.researcherid.com/rid/A-7732-2008
>>
>
_______________________________________________
William I. Gustafson Jr., Ph.D.
Scientist
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
Pacific Northwest National Laboratory
P.O. 999, MSIN K9-30
Richland, WA 99352
Tel: 509-372-6110
William.Gustafson at pnl.gov
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
http://www.researcherid.com/rid/A-7732-2008
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: John Halley Gotway
Time: Fri Apr 29 16:40:33 2011
Bill,
I retrieved your data and ran it through the instance of METv3.0.1 on
my Debian Linux machine compiled using the GNU compilers. Everything
completed without any problems. However I do notice that
the contents of the FCST_LEV output column looks a little odd. It's
set to "P-9999". We've only recently added support for handling the
output of the pinterp tool, and we haven't received much
feedback from users about it yet.
Can you please tell me what compilers you're using to compile MET and
the version numbers for those compilers? Perhaps send me your
Makefile to see if there's anything that jumps out at me.
Thanks,
John
On 04/29/2011 11:20 AM, RAL HelpDesk {for Gustafson, William I} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>
> John,
>
> I put the three files on the ftp site under
> incoming/irap/met_help/gustafson_data. I also included a test
program
> showing what is causing the overflow. The test is in f90 because
that is
> what I know, but I assume the problem is similar in C++. The double
float is
> being assigned into a standard int. The int cannot hold the large
float
> number and an overflow is triggered. If I compile the test program
with "-i8
> -r8" to force long integers in addition to the double float then
everything
> works fine. The sample output is in the top of the testbigint.f90
file if
> you want to look at it. I guess the big question is if the value
being sent
> as the obs_x value is reasonable or not. I don't know the units
being used
> so I am not sure. If the number isn't reasonable, then the overflow
is just
> a symptom. If the value is OK, then the integer needs to be changed
to a
> long.
>
> To temporarily get around the problem, I turned of floating point
checks
> (-Ktrap=fp) when I compiled MET yesterday afternoon. I was able to
get it to
> run to completion this way, but it does this by ignoring the above
problem.
> It makes me a bit nervous. :-)
>
> -Bill
>
>
> On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley Gotway}"
> <met_help at ucar.edu> wrote:
>
>> William,
>>
>> I'm not exactly sure what's going on here. I suspect that you're
right that
>> there's some floating point issue occurring - especially since the
observation
>> apparently occurs exactly at the south pole.
>> Perhaps the grid conversion math is breaking down there. I think
what would
>> be most helpful would be for you to send me some sample data -
specifically,
>> the data you use to run Point-Stat that
>> produces this error:
>> - Forecast file: NetCDF output of pinterp
>> - Observation file: NetCDF file from ds337.0
>> - Configuration file
>>
>> You can post them to our anonymous ftp site using the following
instructions:
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> I'll run it here to try to replicate/debug the problem.
>>
>> Once you've posted the data, please let me know so that I can
retrieve it.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>
>>> Thu Apr 28 15:44:33 2011: Request 46555 was acted upon.
>>> Transaction: Ticket created by william.gustafson at pnl.gov
>>> Queue: met_help
>>> Subject: Floating error in GCPairData::add_obs call to nint
>>> Owner: Nobody
>>> Requestors: william.gustafson at pnl.gov
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>
>>>
>>> Hi,
>>>
>>> I am new to MET and am running into what are probably newbie
issues. As a
>>> first attempt, I¹m trying to run MET for a domain over the central
US using
>>> the obs dataset ds337.0 downloaded from NCAR, which is the
PREPBUFR data
>>> already converted to netCDF. My WRF run is from ARW and the output
has been
>>> interpolated to pressure levels with p_interp. When I run
point_stat using
>>> the attached config file for a single time I keep getting errors
for the
>>> line:
>>>
>>> x = nint(obs_x);
>>>
>>> in GCPairData::add_obs. That line then calls nint, which crashes
at line 37:
>>>
>>> a = (int) y;
>>>
>>> of nint.cc. The specific lat/lon leading to the issue is for the
case
>>> hdr_lat=-90 and hdr_lon=0, which results in
obs_x=11488044980682.4. I assume
>>> that I¹m getting a floating overflow in the integer conversion. I
tried using
>>> a different date for comparison thinking I might have a bad obs
file, but I
>>> get the same error with the same coordinates. If it matters, I am
on a pretty
>>> standard Red Hat Linux system using Portland v11.3 compilers.
>>>
>>> Do you expect that I am doing something wrong? Or, is this a bug?
Given that
>>> I¹ve never run MET before, I am more suspicious of user error. But
I¹m to the
>>> point of seeking help. Thanks for any suggestions.
>>>
>>> -Bill
>>>
>>> _______________________________________________
>>> William I. Gustafson Jr., Ph.D.
>>> Scientist
>>>
>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>> Pacific Northwest National Laboratory
>>> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>> http://www.researcherid.com/rid/A-7732-2008
>>>
>>
>
> _______________________________________________
> William I. Gustafson Jr., Ph.D.
> Scientist
> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>
> Pacific Northwest National Laboratory
> P.O. 999, MSIN K9-30
> Richland, WA 99352
> Tel: 509-372-6110
> William.Gustafson at pnl.gov
> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
> http://www.researcherid.com/rid/A-7732-2008
>
------------------------------------------------
Subject: Floating error in GCPairData::add_obs call to nint
From: Gustafson, William I
Time: Fri Apr 29 17:10:17 2011
John,
The variable I randomly chose to test with is the 2-m
temperature, so
essentially at the surface. I figured -9999 indicated
the surface, which
cannot be easily represented as a pressure level.
But, that is based on a
naive assumption from never having used MET
before this.
Attached is my Makefile. I am using Portland v11.3-0
on Nehalem chips. All
the different libraries are compiles with
Portland except for GSL. Both my
system admin. and I could not get
GSL to pass it's own tests when compiling
with Portland--we tried
v1.11 and v1.14. I ended up just using GSL compiled
with Gnu v4.1.2
and everything linked OK.
-Bill
On 4/29/11 3:40 PM, "RAL
HelpDesk {for John Halley Gotway}"
<met_help at ucar.edu> wrote:
>
Bill,
>
> I retrieved your data and ran it through the instance of
METv3.0.1 on my
> Debian Linux machine compiled using the GNU
compilers. Everything completed
> without any problems. However I
do notice that
> the contents of the FCST_LEV output column looks a
little odd. It's set to
> "P-9999". We've only recently added
support for handling the output of the
> pinterp tool, and we haven't
received much
> feedback from users about it yet.
>
> Can you
please tell me what compilers you're using to compile MET and the
>
version numbers for those compilers? Perhaps send me your Makefile to
see if
> there's anything that jumps out at me.
>
> Thanks,
>
John
>
>
> On 04/29/2011 11:20 AM, RAL HelpDesk {for Gustafson,
William I} wrote:
>>
>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>
>>
John,
>>
>> I put the three files on the ftp site under
>>
incoming/irap/met_help/gustafson_data. I also included a test program
>> showing what is causing the overflow. The test is in f90 because
that is
>> what I know, but I assume the problem is similar in C++.
The double float is
>> being assigned into a standard int. The int
cannot hold the large float
>> number and an overflow is triggered.
If I compile the test program with "-i8
>> -r8" to force long
integers in addition to the double float then everything
>> works
fine. The sample output is in the top of the testbigint.f90 file if
>> you want to look at it. I guess the big question is if the value
being sent
>> as the obs_x value is reasonable or not. I don't know
the units being used
>> so I am not sure. If the number isn't
reasonable, then the overflow is just
>> a symptom. If the value is
OK, then the integer needs to be changed to a
>> long.
>>
>> To
temporarily get around the problem, I turned of floating point checks
>> (-Ktrap=fp) when I compiled MET yesterday afternoon. I was able to
get it to
>> run to completion this way, but it does this by ignoring
the above problem.
>> It makes me a bit nervous. :-)
>>
>> -Bill
>>
>>
>> On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley
Gotway}"
>> <met_help at ucar.edu> wrote:
>>
>>> William,
>>>
>>>
I'm not exactly sure what's going on here. I suspect that you're
right that
>>> there's some floating point issue occurring -
especially since the
>>> observation
>>> apparently occurs exactly
at the south pole.
>>> Perhaps the grid conversion math is breaking
down there. I think what
>>> would
>>> be most helpful would be for
you to send me some sample data - specifically,
>>> the data you use
to run Point-Stat that
>>> produces this error:
>>> - Forecast file:
NetCDF output of pinterp
>>> - Observation file: NetCDF file from
ds337.0
>>> - Configuration file
>>>
>>> You can post them to our
anonymous ftp site using the following
>>> instructions:
>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>
>>>
I'll run it here to try to replicate/debug the problem.
>>>
>>>
Once you've posted the data, please let me know so that I can retrieve
it.
>>>
>>> Thanks,
>>> John Halley Gotway
>>> met_help at ucar.edu
>>>
>>> On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William
I} wrote:
>>>>
>>>> Thu Apr 28 15:44:33 2011: Request 46555 was
acted upon.
>>>> Transaction: Ticket created by
william.gustafson at pnl.gov
>>>> Queue: met_help
>>>>
Subject: Floating error in GCPairData::add_obs call to nint
>>>>
Owner: Nobody
>>>> Requestors: william.gustafson at pnl.gov
>>>>
Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I am new to MET and am running into what are
probably newbie issues. As a
>>>> first attempt, I¹m trying to run
MET for a domain over the central US using
>>>> the obs dataset
ds337.0 downloaded from NCAR, which is the PREPBUFR data
>>>> already
converted to netCDF. My WRF run is from ARW and the output has been
>>>> interpolated to pressure levels with p_interp. When I run
point_stat using
>>>> the attached config file for a single time I
keep getting errors for the
>>>> line:
>>>>
>>>> x =
nint(obs_x);
>>>>
>>>> in GCPairData::add_obs. That line then calls
nint, which crashes at line
>>>> 37:
>>>>
>>>> a = (int) y;
>>>>
>>>> of nint.cc. The specific lat/lon leading to the issue is
for the case
>>>> hdr_lat=-90 and hdr_lon=0, which results in
obs_x=11488044980682.4. I
>>>> assume
>>>> that I¹m getting a
floating overflow in the integer conversion. I tried
>>>> using
>>>>
a different date for comparison thinking I might have a bad obs file,
but I
>>>> get the same error with the same coordinates. If it
matters, I am on a
>>>> pretty
>>>> standard Red Hat Linux system
using Portland v11.3 compilers.
>>>>
>>>> Do you expect that I am
doing something wrong? Or, is this a bug? Given
>>>> that
>>>> I¹ve
never run MET before, I am more suspicious of user error. But I¹m to
>>>> the
>>>> point of seeking help. Thanks for any suggestions.
>>>>
>>>> -Bill
>>>>
>>>>
_______________________________________________
>>>> William I.
Gustafson Jr., Ph.D.
>>>> Scientist
>>>>
>>>> ATMOSPHERIC SCIENCES
AND GLOBAL CHANGE DIVISION
>>>> Pacific Northwest National Laboratory
>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>
>>>
>>
>>
_______________________________________________
>> William I.
Gustafson Jr., Ph.D.
>> Scientist
>> ATMOSPHERIC SCIENCES AND GLOBAL
CHANGE DIVISION
>>
>> Pacific Northwest National Laboratory
>>
P.O. 999, MSIN K9-30
>> Richland, WA 99352
>> Tel: 509-372-6110
>>
William.Gustafson at pnl.gov
>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>
http://www.researcherid.com/rid/A-7732-2008
>>
>
_______________________________________________
William I. Gustafson
Jr., Ph.D.
Scientist
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
Pacific Northwest National Laboratory
P.O. 999, MSIN K9-30
Richland,
WA 99352
Tel: 509-372-6110
William.Gustafson at pnl.gov
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
http://www.researcherid.com/rid/A-7732-2008
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: John Halley Gotway
Time: Fri Apr 29 19:50:24 2011
Bill,
Great. Thanks for sending this info. I'll take a look at it when I
get a
chance next week.
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>
> John,
>
> The variable I randomly chose to test with is the 2-m temperature,
so
> essentially at the surface. I figured -9999 indicated the surface,
which
> cannot be easily represented as a pressure level. But, that is based
on a
> naive assumption from never having used MET before this.
>
> Attached is my Makefile. I am using Portland v11.3-0 on Nehalem
chips. All
> the different libraries are compiles with Portland except for GSL.
Both my
> system admin. and I could not get GSL to pass it's own tests when
> compiling
> with Portland--we tried v1.11 and v1.14. I ended up just using GSL
> compiled
> with Gnu v4.1.2 and everything linked OK.
>
> -Bill
>
>
> On 4/29/11 3:40 PM, "RAL HelpDesk {for John Halley Gotway}"
> <met_help at ucar.edu> wrote:
>
>> Bill,
>>
>> I retrieved your data and ran it through the instance of METv3.0.1
on my
>> Debian Linux machine compiled using the GNU compilers. Everything
>> completed
>> without any problems. However I do notice that
>> the contents of the FCST_LEV output column looks a little odd.
It's set
>> to
>> "P-9999". We've only recently added support for handling the
output of
>> the
>> pinterp tool, and we haven't received much
>> feedback from users about it yet.
>>
>> Can you please tell me what compilers you're using to compile MET
and
>> the
>> version numbers for those compilers? Perhaps send me your Makefile
to
>> see if
>> there's anything that jumps out at me.
>>
>> Thanks,
>> John
>>
>>
>> On 04/29/2011 11:20 AM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>
>>> John,
>>>
>>> I put the three files on the ftp site under
>>> incoming/irap/met_help/gustafson_data. I also included a test
program
>>> showing what is causing the overflow. The test is in f90 because
that
>>> is
>>> what I know, but I assume the problem is similar in C++. The
double
>>> float is
>>> being assigned into a standard int. The int cannot hold the large
float
>>> number and an overflow is triggered. If I compile the test program
with
>>> "-i8
>>> -r8" to force long integers in addition to the double float then
>>> everything
>>> works fine. The sample output is in the top of the testbigint.f90
file
>>> if
>>> you want to look at it. I guess the big question is if the value
being
>>> sent
>>> as the obs_x value is reasonable or not. I don't know the units
being
>>> used
>>> so I am not sure. If the number isn't reasonable, then the
overflow is
>>> just
>>> a symptom. If the value is OK, then the integer needs to be
changed to
>>> a
>>> long.
>>>
>>> To temporarily get around the problem, I turned of floating point
>>> checks
>>> (-Ktrap=fp) when I compiled MET yesterday afternoon. I was able to
get
>>> it to
>>> run to completion this way, but it does this by ignoring the above
>>> problem.
>>> It makes me a bit nervous. :-)
>>>
>>> -Bill
>>>
>>>
>>> On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley Gotway}"
>>> <met_help at ucar.edu> wrote:
>>>
>>>> William,
>>>>
>>>> I'm not exactly sure what's going on here. I suspect that you're
>>>> right that
>>>> there's some floating point issue occurring - especially since
the
>>>> observation
>>>> apparently occurs exactly at the south pole.
>>>> Perhaps the grid conversion math is breaking down there. I
think
>>>> what
>>>> would
>>>> be most helpful would be for you to send me some sample data -
>>>> specifically,
>>>> the data you use to run Point-Stat that
>>>> produces this error:
>>>> - Forecast file: NetCDF output of pinterp
>>>> - Observation file: NetCDF file from ds337.0
>>>> - Configuration file
>>>>
>>>> You can post them to our anonymous ftp site using the following
>>>> instructions:
>>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>
>>>> I'll run it here to try to replicate/debug the problem.
>>>>
>>>> Once you've posted the data, please let me know so that I can
retrieve
>>>> it.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> met_help at ucar.edu
>>>>
>>>> On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>>>
>>>>> Thu Apr 28 15:44:33 2011: Request 46555 was acted upon.
>>>>> Transaction: Ticket created by william.gustafson at pnl.gov
>>>>> Queue: met_help
>>>>> Subject: Floating error in GCPairData::add_obs call to nint
>>>>> Owner: Nobody
>>>>> Requestors: william.gustafson at pnl.gov
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555
>>>>> >
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am new to MET and am running into what are probably newbie
issues.
>>>>> As a
>>>>> first attempt, I¹m trying to run MET for a domain over the
central
>>>>> US using
>>>>> the obs dataset ds337.0 downloaded from NCAR, which is the
PREPBUFR
>>>>> data
>>>>> already converted to netCDF. My WRF run is from ARW and the
output
>>>>> has been
>>>>> interpolated to pressure levels with p_interp. When I run
point_stat
>>>>> using
>>>>> the attached config file for a single time I keep getting errors
for
>>>>> the
>>>>> line:
>>>>>
>>>>> x = nint(obs_x);
>>>>>
>>>>> in GCPairData::add_obs. That line then calls nint, which crashes
at
>>>>> line
>>>>> 37:
>>>>>
>>>>> a = (int) y;
>>>>>
>>>>> of nint.cc. The specific lat/lon leading to the issue is for the
case
>>>>> hdr_lat=-90 and hdr_lon=0, which results in
obs_x=11488044980682.4.
>>>>> I
>>>>> assume
>>>>> that I¹m getting a floating overflow in the integer conversion.
I
>>>>> tried
>>>>> using
>>>>> a different date for comparison thinking I might have a bad obs
file,
>>>>> but I
>>>>> get the same error with the same coordinates. If it matters, I
am on
>>>>> a
>>>>> pretty
>>>>> standard Red Hat Linux system using Portland v11.3 compilers.
>>>>>
>>>>> Do you expect that I am doing something wrong? Or, is this a
bug?
>>>>> Given
>>>>> that
>>>>> I¹ve never run MET before, I am more suspicious of user error.
But
>>>>> I¹m to
>>>>> the
>>>>> point of seeking help. Thanks for any suggestions.
>>>>>
>>>>> -Bill
>>>>>
>>>>> _______________________________________________
>>>>> William I. Gustafson Jr., Ph.D.
>>>>> Scientist
>>>>>
>>>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>>> Pacific Northwest National Laboratory
>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> William I. Gustafson Jr., Ph.D.
>>> Scientist
>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>
>>> Pacific Northwest National Laboratory
>>> P.O. 999, MSIN K9-30
>>> Richland, WA 99352
>>> Tel: 509-372-6110
>>> William.Gustafson at pnl.gov
>>> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>> http://www.researcherid.com/rid/A-7732-2008
>>>
>>
>
> _______________________________________________
> William I. Gustafson Jr., Ph.D.
> Scientist
> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>
> Pacific Northwest National Laboratory
> P.O. 999, MSIN K9-30
> Richland, WA 99352
> Tel: 509-372-6110
> William.Gustafson at pnl.gov
> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
> http://www.researcherid.com/rid/A-7732-2008
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: Gustafson, William I
Time: Mon May 02 11:13:17 2011
John,
I remembered over the weekend that the Makefile I sent you
probably has the
error trapping turned off for CXX_FLAGS and
FC_FLAGS. The crash happens when
I turn on -Ktrap=fp.
-Bill
On 4/29/11 6:50 PM, "RAL HelpDesk {for John Halley Gotway}"
<met_help at ucar.edu> wrote:
> Bill,
>
> Great. Thanks for
sending this info. I'll take a look at it when I get a
> chance next
week.
>
> Thanks,
> John
>
>>
>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>
>>
John,
>>
>> The variable I randomly chose to test with is the 2-m
temperature, so
>> essentially at the surface. I figured -9999
indicated the surface, which
>> cannot be easily represented as a
pressure level. But, that is based on a
>> naive assumption from
never having used MET before this.
>>
>> Attached is my Makefile. I
am using Portland v11.3-0 on Nehalem chips. All
>> the different
libraries are compiles with Portland except for GSL. Both my
>>
system admin. and I could not get GSL to pass it's own tests when
>>
compiling
>> with Portland--we tried v1.11 and v1.14. I ended up just
using GSL
>> compiled
>> with Gnu v4.1.2 and everything linked OK.
>>
>> -Bill
>>
>>
>> On 4/29/11 3:40 PM, "RAL HelpDesk {for
John Halley Gotway}"
>> <met_help at ucar.edu> wrote:
>>
>>> Bill,
>>>
>>> I retrieved your data and ran it through the instance of
METv3.0.1 on my
>>> Debian Linux machine compiled using the GNU
compilers. Everything
>>> completed
>>> without any problems.
However I do notice that
>>> the contents of the FCST_LEV output
column looks a little odd. It's set
>>> to
>>> "P-9999". We've
only recently added support for handling the output of
>>> the
>>>
pinterp tool, and we haven't received much
>>> feedback from users
about it yet.
>>>
>>> Can you please tell me what compilers you're
using to compile MET and
>>> the
>>> version numbers for those
compilers? Perhaps send me your Makefile to
>>> see if
>>> there's
anything that jumps out at me.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 04/29/2011 11:20 AM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>>
>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>>
>>>>
John,
>>>>
>>>> I put the three files on the ftp site under
>>>>
incoming/irap/met_help/gustafson_data. I also included a test program
>>>> showing what is causing the overflow. The test is in f90 because
that
>>>> is
>>>> what I know, but I assume the problem is similar
in C++. The double
>>>> float is
>>>> being assigned into a standard
int. The int cannot hold the large float
>>>> number and an overflow
is triggered. If I compile the test program with
>>>> "-i8
>>>> -r8"
to force long integers in addition to the double float then
>>>>
everything
>>>> works fine. The sample output is in the top of the
testbigint.f90 file
>>>> if
>>>> you want to look at it. I guess the
big question is if the value being
>>>> sent
>>>> as the obs_x value
is reasonable or not. I don't know the units being
>>>> used
>>>> so
I am not sure. If the number isn't reasonable, then the overflow is
>>>> just
>>>> a symptom. If the value is OK, then the integer needs
to be changed to
>>>> a
>>>> long.
>>>>
>>>> To temporarily get
around the problem, I turned of floating point
>>>> checks
>>>> (-
Ktrap=fp) when I compiled MET yesterday afternoon. I was able to get
>>>> it to
>>>> run to completion this way, but it does this by
ignoring the above
>>>> problem.
>>>> It makes me a bit nervous. :-)
>>>>
>>>> -Bill
>>>>
>>>>
>>>> On 4/29/11 8:37 AM, "RAL
HelpDesk {for John Halley Gotway}"
>>>> <met_help at ucar.edu> wrote:
>>>>
>>>>> William,
>>>>>
>>>>> I'm not exactly sure what's going
on here. I suspect that you're
>>>>> right that
>>>>> there's some
floating point issue occurring - especially since the
>>>>>
observation
>>>>> apparently occurs exactly at the south pole.
>>>>>
Perhaps the grid conversion math is breaking down there. I think
>>>>> what
>>>>> would
>>>>> be most helpful would be for you to
send me some sample data -
>>>>> specifically,
>>>>> the data you
use to run Point-Stat that
>>>>> produces this error:
>>>>> -
Forecast file: NetCDF output of pinterp
>>>>> - Observation file:
NetCDF file from ds337.0
>>>>> - Configuration file
>>>>>
>>>>>
You can post them to our anonymous ftp site using the following
>>>>>
instructions:
>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>
>>>>> I'll run it here to try to replicate/debug the problem.
>>>>>
>>>>> Once you've posted the data, please let me know so that I can
retrieve
>>>>> it.
>>>>>
>>>>> Thanks,
>>>>> John Halley Gotway
>>>>> met_help at ucar.edu
>>>>>
>>>>> On 04/28/2011 03:44 PM, RAL
HelpDesk {for Gustafson, William I} wrote:
>>>>>>
>>>>>> Thu Apr 28
15:44:33 2011: Request 46555 was acted upon.
>>>>>> Transaction:
Ticket created by william.gustafson at pnl.gov
>>>>>> Queue:
met_help
>>>>>> Subject: Floating error in GCPairData::add_obs
call to nint
>>>>>> Owner: Nobody
>>>>>> Requestors:
william.gustafson at pnl.gov
>>>>>> Status: new
>>>>>> Ticket
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am new to MET and am
running into what are probably newbie issues.
>>>>>> As a
>>>>>>
first attempt, I¹m trying to run MET for a domain over the central
>>>>>> US using
>>>>>> the obs dataset ds337.0 downloaded from NCAR,
which is the PREPBUFR
>>>>>> data
>>>>>> already converted to
netCDF. My WRF run is from ARW and the output
>>>>>> has been
>>>>>>
interpolated to pressure levels with p_interp. When I run point_stat
>>>>>> using
>>>>>> the attached config file for a single time I keep
getting errors for
>>>>>> the
>>>>>> line:
>>>>>>
>>>>>> x =
nint(obs_x);
>>>>>>
>>>>>> in GCPairData::add_obs. That line then
calls nint, which crashes at
>>>>>> line
>>>>>> 37:
>>>>>>
>>>>>>
a = (int) y;
>>>>>>
>>>>>> of nint.cc. The specific lat/lon leading
to the issue is for the case
>>>>>> hdr_lat=-90 and hdr_lon=0, which
results in obs_x=11488044980682.4.
>>>>>> I
>>>>>> assume
>>>>>>
that I¹m getting a floating overflow in the integer conversion. I
>>>>>> tried
>>>>>> using
>>>>>> a different date for comparison
thinking I might have a bad obs file,
>>>>>> but I
>>>>>> get the
same error with the same coordinates. If it matters, I am on
>>>>>> a
>>>>>> pretty
>>>>>> standard Red Hat Linux system using Portland
v11.3 compilers.
>>>>>>
>>>>>> Do you expect that I am doing
something wrong? Or, is this a bug?
>>>>>> Given
>>>>>> that
>>>>>>
I¹ve never run MET before, I am more suspicious of user error. But
>>>>>> I¹m to
>>>>>> the
>>>>>> point of seeking help. Thanks for
any suggestions.
>>>>>>
>>>>>> -Bill
>>>>>>
>>>>>>
_______________________________________________
>>>>>> William I.
Gustafson Jr., Ph.D.
>>>>>> Scientist
>>>>>>
>>>>>> ATMOSPHERIC
SCIENCES AND GLOBAL CHANGE DIVISION
>>>>>> Pacific Northwest National
Laboratory
>>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>>
William I. Gustafson Jr., Ph.D.
>>>> Scientist
>>>> ATMOSPHERIC
SCIENCES AND GLOBAL CHANGE DIVISION
>>>>
>>>> Pacific Northwest
National Laboratory
>>>> P.O. 999, MSIN K9-30
>>>> Richland, WA
99352
>>>> Tel: 509-372-6110
>>>> William.Gustafson at pnl.gov
>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>
>>>
>>
>>
_______________________________________________
>> William I.
Gustafson Jr., Ph.D.
>> Scientist
>> ATMOSPHERIC SCIENCES AND GLOBAL
CHANGE DIVISION
>>
>> Pacific Northwest National Laboratory
>>
P.O. 999, MSIN K9-30
>> Richland, WA 99352
>> Tel: 509-372-6110
>>
William.Gustafson at pnl.gov
>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>
http://www.researcherid.com/rid/A-7732-2008
>>
>>
>>
>
>
>
_______________________________________________
William I. Gustafson
Jr., Ph.D.
Scientist
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
Pacific Northwest National Laboratory
P.O. 999, MSIN K9-30
Richland,
WA 99352
Tel: 509-372-6110
William.Gustafson at pnl.gov
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
http://www.researcherid.com/rid/A-7732-2008
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: John Halley Gotway
Time: Mon May 02 13:48:36 2011
Bill,
Thanks for the details. When I recompiled MET with PGI using the
-Ktrap=fp option, I was able to reproduce the floating point
exception. We hadn't been testing the code using that option, but
doing
so is a great idea. We're beginning development for the next release
of MET soon, and I'll add this testing to the list of our development
tasks. I suspect we'll need to clean things up in more than
one place.
For now, I'd suggest compiling and running without that option.
Thanks,
John
On 05/02/2011 11:13 AM, RAL HelpDesk {for Gustafson, William I} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>
> John,
>
> I remembered over the weekend that the Makefile I sent you probably
has the
> error trapping turned off for CXX_FLAGS and FC_FLAGS. The crash
happens when
> I turn on -Ktrap=fp.
>
> -Bill
>
>
> On 4/29/11 6:50 PM, "RAL HelpDesk {for John Halley Gotway}"
> <met_help at ucar.edu> wrote:
>
>> Bill,
>>
>> Great. Thanks for sending this info. I'll take a look at it when
I get a
>> chance next week.
>>
>> Thanks,
>> John
>>
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>
>>> John,
>>>
>>> The variable I randomly chose to test with is the 2-m temperature,
so
>>> essentially at the surface. I figured -9999 indicated the surface,
which
>>> cannot be easily represented as a pressure level. But, that is
based on a
>>> naive assumption from never having used MET before this.
>>>
>>> Attached is my Makefile. I am using Portland v11.3-0 on Nehalem
chips. All
>>> the different libraries are compiles with Portland except for GSL.
Both my
>>> system admin. and I could not get GSL to pass it's own tests when
>>> compiling
>>> with Portland--we tried v1.11 and v1.14. I ended up just using GSL
>>> compiled
>>> with Gnu v4.1.2 and everything linked OK.
>>>
>>> -Bill
>>>
>>>
>>> On 4/29/11 3:40 PM, "RAL HelpDesk {for John Halley Gotway}"
>>> <met_help at ucar.edu> wrote:
>>>
>>>> Bill,
>>>>
>>>> I retrieved your data and ran it through the instance of
METv3.0.1 on my
>>>> Debian Linux machine compiled using the GNU compilers.
Everything
>>>> completed
>>>> without any problems. However I do notice that
>>>> the contents of the FCST_LEV output column looks a little odd.
It's set
>>>> to
>>>> "P-9999". We've only recently added support for handling the
output of
>>>> the
>>>> pinterp tool, and we haven't received much
>>>> feedback from users about it yet.
>>>>
>>>> Can you please tell me what compilers you're using to compile MET
and
>>>> the
>>>> version numbers for those compilers? Perhaps send me your
Makefile to
>>>> see if
>>>> there's anything that jumps out at me.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 04/29/2011 11:20 AM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>>>
>>>>> John,
>>>>>
>>>>> I put the three files on the ftp site under
>>>>> incoming/irap/met_help/gustafson_data. I also included a test
program
>>>>> showing what is causing the overflow. The test is in f90 because
that
>>>>> is
>>>>> what I know, but I assume the problem is similar in C++. The
double
>>>>> float is
>>>>> being assigned into a standard int. The int cannot hold the
large float
>>>>> number and an overflow is triggered. If I compile the test
program with
>>>>> "-i8
>>>>> -r8" to force long integers in addition to the double float then
>>>>> everything
>>>>> works fine. The sample output is in the top of the
testbigint.f90 file
>>>>> if
>>>>> you want to look at it. I guess the big question is if the value
being
>>>>> sent
>>>>> as the obs_x value is reasonable or not. I don't know the units
being
>>>>> used
>>>>> so I am not sure. If the number isn't reasonable, then the
overflow is
>>>>> just
>>>>> a symptom. If the value is OK, then the integer needs to be
changed to
>>>>> a
>>>>> long.
>>>>>
>>>>> To temporarily get around the problem, I turned of floating
point
>>>>> checks
>>>>> (-Ktrap=fp) when I compiled MET yesterday afternoon. I was able
to get
>>>>> it to
>>>>> run to completion this way, but it does this by ignoring the
above
>>>>> problem.
>>>>> It makes me a bit nervous. :-)
>>>>>
>>>>> -Bill
>>>>>
>>>>>
>>>>> On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley Gotway}"
>>>>> <met_help at ucar.edu> wrote:
>>>>>
>>>>>> William,
>>>>>>
>>>>>> I'm not exactly sure what's going on here. I suspect that
you're
>>>>>> right that
>>>>>> there's some floating point issue occurring - especially since
the
>>>>>> observation
>>>>>> apparently occurs exactly at the south pole.
>>>>>> Perhaps the grid conversion math is breaking down there. I
think
>>>>>> what
>>>>>> would
>>>>>> be most helpful would be for you to send me some sample data -
>>>>>> specifically,
>>>>>> the data you use to run Point-Stat that
>>>>>> produces this error:
>>>>>> - Forecast file: NetCDF output of pinterp
>>>>>> - Observation file: NetCDF file from ds337.0
>>>>>> - Configuration file
>>>>>>
>>>>>> You can post them to our anonymous ftp site using the following
>>>>>> instructions:
>>>>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>
>>>>>> I'll run it here to try to replicate/debug the problem.
>>>>>>
>>>>>> Once you've posted the data, please let me know so that I can
retrieve
>>>>>> it.
>>>>>>
>>>>>> Thanks,
>>>>>> John Halley Gotway
>>>>>> met_help at ucar.edu
>>>>>>
>>>>>> On 04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I}
wrote:
>>>>>>>
>>>>>>> Thu Apr 28 15:44:33 2011: Request 46555 was acted upon.
>>>>>>> Transaction: Ticket created by william.gustafson at pnl.gov
>>>>>>> Queue: met_help
>>>>>>> Subject: Floating error in GCPairData::add_obs call to
nint
>>>>>>> Owner: Nobody
>>>>>>> Requestors: william.gustafson at pnl.gov
>>>>>>> Status: new
>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am new to MET and am running into what are probably newbie
issues.
>>>>>>> As a
>>>>>>> first attempt, I¹m trying to run MET for a domain over the
central
>>>>>>> US using
>>>>>>> the obs dataset ds337.0 downloaded from NCAR, which is the
PREPBUFR
>>>>>>> data
>>>>>>> already converted to netCDF. My WRF run is from ARW and the
output
>>>>>>> has been
>>>>>>> interpolated to pressure levels with p_interp. When I run
point_stat
>>>>>>> using
>>>>>>> the attached config file for a single time I keep getting
errors for
>>>>>>> the
>>>>>>> line:
>>>>>>>
>>>>>>> x = nint(obs_x);
>>>>>>>
>>>>>>> in GCPairData::add_obs. That line then calls nint, which
crashes at
>>>>>>> line
>>>>>>> 37:
>>>>>>>
>>>>>>> a = (int) y;
>>>>>>>
>>>>>>> of nint.cc. The specific lat/lon leading to the issue is for
the case
>>>>>>> hdr_lat=-90 and hdr_lon=0, which results in
obs_x=11488044980682.4.
>>>>>>> I
>>>>>>> assume
>>>>>>> that I¹m getting a floating overflow in the integer
conversion. I
>>>>>>> tried
>>>>>>> using
>>>>>>> a different date for comparison thinking I might have a bad
obs file,
>>>>>>> but I
>>>>>>> get the same error with the same coordinates. If it matters, I
am on
>>>>>>> a
>>>>>>> pretty
>>>>>>> standard Red Hat Linux system using Portland v11.3 compilers.
>>>>>>>
>>>>>>> Do you expect that I am doing something wrong? Or, is this a
bug?
>>>>>>> Given
>>>>>>> that
>>>>>>> I¹ve never run MET before, I am more suspicious of user
error. But
>>>>>>> I¹m to
>>>>>>> the
>>>>>>> point of seeking help. Thanks for any suggestions.
>>>>>>>
>>>>>>> -Bill
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> William I. Gustafson Jr., Ph.D.
>>>>>>> Scientist
>>>>>>>
>>>>>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>>>>> Pacific Northwest National Laboratory
>>>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> William I. Gustafson Jr., Ph.D.
>>>>> Scientist
>>>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>>>
>>>>> Pacific Northwest National Laboratory
>>>>> P.O. 999, MSIN K9-30
>>>>> Richland, WA 99352
>>>>> Tel: 509-372-6110
>>>>> William.Gustafson at pnl.gov
>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> William I. Gustafson Jr., Ph.D.
>>> Scientist
>>> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>
>>> Pacific Northwest National Laboratory
>>> P.O. 999, MSIN K9-30
>>> Richland, WA 99352
>>> Tel: 509-372-6110
>>> William.Gustafson at pnl.gov
>>> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>> http://www.researcherid.com/rid/A-7732-2008
>>>
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> William I. Gustafson Jr., Ph.D.
> Scientist
> ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>
> Pacific Northwest National Laboratory
> P.O. 999, MSIN K9-30
> Richland, WA 99352
> Tel: 509-372-6110
> William.Gustafson at pnl.gov
> http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
> http://www.researcherid.com/rid/A-7732-2008
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #46555] Floating error in GCPairData::add_obs call to nint
From: Gustafson, William I
Time: Mon May 02 16:50:34 2011
John,
Thanks. I'll keep my fingers crossed and hope the results
come out fine. :-)
-Bill
On 5/2/11 12:48 PM, "RAL HelpDesk
{for John Halley Gotway}"
<met_help at ucar.edu> wrote:
> Bill,
>
> Thanks for the details. When I recompiled MET with PGI using the
-Ktrap=fp
> option, I was able to reproduce the floating point
exception. We hadn't been
> testing the code using that option, but
doing
> so is a great idea. We're beginning development for the next
release of MET
> soon, and I'll add this testing to the list of our
development tasks. I
> suspect we'll need to clean things up in more
than
> one place.
>
> For now, I'd suggest compiling and running
without that option.
>
> Thanks,
> John
>
> On 05/02/2011 11:13
AM, RAL HelpDesk {for Gustafson, William I} wrote:
>>
>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>
>>
John,
>>
>> I remembered over the weekend that the Makefile I sent
you probably has the
>> error trapping turned off for CXX_FLAGS and
FC_FLAGS. The crash happens when
>> I turn on -Ktrap=fp.
>>
>>
-Bill
>>
>>
>> On 4/29/11 6:50 PM, "RAL HelpDesk {for John Halley
Gotway}"
>> <met_help at ucar.edu> wrote:
>>
>>> Bill,
>>>
>>>
Great. Thanks for sending this info. I'll take a look at it when I
get a
>>> chance next week.
>>>
>>> Thanks,
>>> John
>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>>
>>>> John,
>>>>
>>>> The variable I randomly chose to test
with is the 2-m temperature, so
>>>> essentially at the surface. I
figured -9999 indicated the surface, which
>>>> cannot be easily
represented as a pressure level. But, that is based on a
>>>> naive
assumption from never having used MET before this.
>>>>
>>>>
Attached is my Makefile. I am using Portland v11.3-0 on Nehalem chips.
All
>>>> the different libraries are compiles with Portland except
for GSL. Both my
>>>> system admin. and I could not get GSL to pass
it's own tests when
>>>> compiling
>>>> with Portland--we tried
v1.11 and v1.14. I ended up just using GSL
>>>> compiled
>>>> with
Gnu v4.1.2 and everything linked OK.
>>>>
>>>> -Bill
>>>>
>>>>
>>>> On 4/29/11 3:40 PM, "RAL HelpDesk {for John Halley Gotway}"
>>>>
<met_help at ucar.edu> wrote:
>>>>
>>>>> Bill,
>>>>>
>>>>> I
retrieved your data and ran it through the instance of METv3.0.1 on my
>>>>> Debian Linux machine compiled using the GNU compilers.
Everything
>>>>> completed
>>>>> without any problems. However I do
notice that
>>>>> the contents of the FCST_LEV output column looks a
little odd. It's set
>>>>> to
>>>>> "P-9999". We've only recently
added support for handling the output of
>>>>> the
>>>>> pinterp
tool, and we haven't received much
>>>>> feedback from users about it
yet.
>>>>>
>>>>> Can you please tell me what compilers you're using
to compile MET and
>>>>> the
>>>>> version numbers for those
compilers? Perhaps send me your Makefile to
>>>>> see if
>>>>>
there's anything that jumps out at me.
>>>>>
>>>>> Thanks,
>>>>>
John
>>>>>
>>>>>
>>>>> On 04/29/2011 11:20 AM, RAL HelpDesk {for
Gustafson, William I} wrote:
>>>>>>
>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555 >
>>>>>>
>>>>>> John,
>>>>>>
>>>>>> I put the three files on the ftp site
under
>>>>>> incoming/irap/met_help/gustafson_data. I also included a
test program
>>>>>> showing what is causing the overflow. The test is
in f90 because that
>>>>>> is
>>>>>> what I know, but I assume the
problem is similar in C++. The double
>>>>>> float is
>>>>>> being
assigned into a standard int. The int cannot hold the large float
>>>>>> number and an overflow is triggered. If I compile the test
program with
>>>>>> "-i8
>>>>>> -r8" to force long integers in
addition to the double float then
>>>>>> everything
>>>>>> works
fine. The sample output is in the top of the testbigint.f90 file
>>>>>> if
>>>>>> you want to look at it. I guess the big question is
if the value being
>>>>>> sent
>>>>>> as the obs_x value is
reasonable or not. I don't know the units being
>>>>>> used
>>>>>>
so I am not sure. If the number isn't reasonable, then the overflow is
>>>>>> just
>>>>>> a symptom. If the value is OK, then the integer
needs to be changed to
>>>>>> a
>>>>>> long.
>>>>>>
>>>>>> To
temporarily get around the problem, I turned of floating point
>>>>>>
checks
>>>>>> (-Ktrap=fp) when I compiled MET yesterday afternoon. I
was able to get
>>>>>> it to
>>>>>> run to completion this way, but
it does this by ignoring the above
>>>>>> problem.
>>>>>> It makes
me a bit nervous. :-)
>>>>>>
>>>>>> -Bill
>>>>>>
>>>>>>
>>>>>>
On 4/29/11 8:37 AM, "RAL HelpDesk {for John Halley Gotway}"
>>>>>>
<met_help at ucar.edu> wrote:
>>>>>>
>>>>>>> William,
>>>>>>>
>>>>>>> I'm not exactly sure what's going on here. I suspect that
you're
>>>>>>> right that
>>>>>>> there's some floating point issue
occurring - especially since the
>>>>>>> observation
>>>>>>>
apparently occurs exactly at the south pole.
>>>>>>> Perhaps the
grid conversion math is breaking down there. I think
>>>>>>> what
>>>>>>> would
>>>>>>> be most helpful would be for you to send me
some sample data -
>>>>>>> specifically,
>>>>>>> the data you use to
run Point-Stat that
>>>>>>> produces this error:
>>>>>>> - Forecast
file: NetCDF output of pinterp
>>>>>>> - Observation file: NetCDF
file from ds337.0
>>>>>>> - Configuration file
>>>>>>>
>>>>>>> You
can post them to our anonymous ftp site using the following
>>>>>>>
instructions:
>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>
>>>>>>> I'll run it here to try to replicate/debug the problem.
>>>>>>>
>>>>>>> Once you've posted the data, please let me know so
that I can retrieve
>>>>>>> it.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
John Halley Gotway
>>>>>>> met_help at ucar.edu
>>>>>>>
>>>>>>> On
04/28/2011 03:44 PM, RAL HelpDesk {for Gustafson, William I} wrote:
>>>>>>>>
>>>>>>>> Thu Apr 28 15:44:33 2011: Request 46555 was acted
upon.
>>>>>>>> Transaction: Ticket created by
william.gustafson at pnl.gov
>>>>>>>> Queue: met_help
>>>>>>>>
Subject: Floating error in GCPairData::add_obs call to nint
>>>>>>>>
Owner: Nobody
>>>>>>>> Requestors: william.gustafson at pnl.gov
>>>>>>>> Status: new
>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=46555
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am new to
MET and am running into what are probably newbie issues.
>>>>>>>> As
a
>>>>>>>> first attempt, I¹m trying to run MET for a domain over
the central
>>>>>>>> US using
>>>>>>>> the obs dataset ds337.0
downloaded from NCAR, which is the PREPBUFR
>>>>>>>> data
>>>>>>>>
already converted to netCDF. My WRF run is from ARW and the output
>>>>>>>> has been
>>>>>>>> interpolated to pressure levels with
p_interp. When I run point_stat
>>>>>>>> using
>>>>>>>> the attached
config file for a single time I keep getting errors for
>>>>>>>> the
>>>>>>>> line:
>>>>>>>>
>>>>>>>> x = nint(obs_x);
>>>>>>>>
>>>>>>>> in GCPairData::add_obs. That line then calls nint, which
crashes at
>>>>>>>> line
>>>>>>>> 37:
>>>>>>>>
>>>>>>>> a =
(int) y;
>>>>>>>>
>>>>>>>> of nint.cc. The specific lat/lon leading
to the issue is for the case
>>>>>>>> hdr_lat=-90 and hdr_lon=0,
which results in obs_x=11488044980682.4.
>>>>>>>> I
>>>>>>>> assume
>>>>>>>> that I¹m getting a floating overflow in the integer
conversion. I
>>>>>>>> tried
>>>>>>>> using
>>>>>>>> a different
date for comparison thinking I might have a bad obs file,
>>>>>>>>
but I
>>>>>>>> get the same error with the same coordinates. If it
matters, I am on
>>>>>>>> a
>>>>>>>> pretty
>>>>>>>> standard Red
Hat Linux system using Portland v11.3 compilers.
>>>>>>>>
>>>>>>>>
Do you expect that I am doing something wrong? Or, is this a bug?
>>>>>>>> Given
>>>>>>>> that
>>>>>>>> I¹ve never run MET before, I
am more suspicious of user error. But
>>>>>>>> I¹m to
>>>>>>>> the
>>>>>>>> point of seeking help. Thanks for any suggestions.
>>>>>>>>
>>>>>>>> -Bill
>>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>>> William I.
Gustafson Jr., Ph.D.
>>>>>>>> Scientist
>>>>>>>>
>>>>>>>>
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
>>>>>>>> Pacific
Northwest National Laboratory
>>>>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
_______________________________________________
>>>>>> William I.
Gustafson Jr., Ph.D.
>>>>>> Scientist
>>>>>> ATMOSPHERIC SCIENCES
AND GLOBAL CHANGE DIVISION
>>>>>>
>>>>>> Pacific Northwest National
Laboratory
>>>>>> P.O. 999, MSIN K9-30
>>>>>> Richland, WA 99352
>>>>>> Tel: 509-372-6110
>>>>>> William.Gustafson at pnl.gov
>>>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>>
William I. Gustafson Jr., Ph.D.
>>>> Scientist
>>>> ATMOSPHERIC
SCIENCES AND GLOBAL CHANGE DIVISION
>>>>
>>>> Pacific Northwest
National Laboratory
>>>> P.O. 999, MSIN K9-30
>>>> Richland, WA
99352
>>>> Tel: 509-372-6110
>>>> William.Gustafson at pnl.gov
>>>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>>> http://www.researcherid.com/rid/A-7732-2008
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
_______________________________________________
>> William I.
Gustafson Jr., Ph.D.
>> Scientist
>> ATMOSPHERIC SCIENCES AND GLOBAL
CHANGE DIVISION
>>
>> Pacific Northwest National Laboratory
>>
P.O. 999, MSIN K9-30
>> Richland, WA 99352
>> Tel: 509-372-6110
>>
William.Gustafson at pnl.gov
>>
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
>>
http://www.researcherid.com/rid/A-7732-2008
>>
>
_______________________________________________
William I. Gustafson
Jr., Ph.D.
Scientist
ATMOSPHERIC SCIENCES AND GLOBAL CHANGE DIVISION
Pacific Northwest National Laboratory
P.O. 999, MSIN K9-30
Richland,
WA 99352
Tel: 509-372-6110
William.Gustafson at pnl.gov
http://www.pnl.gov/atmospheric/staff/staff_info.asp?staff_num=5716
http://www.researcherid.com/rid/A-7732-2008
------------------------------------------------
More information about the Met_help
mailing list