[Met_help] [rt.rap.ucar.edu #92478] History for PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan

John Halley Gotway via RT met_help at ucar.edu
Tue Nov 19 09:19:51 MST 2019


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

Hi,

I'm getting the error PiecewiseLinear::operator()(double) -> error in 
"aspect_diff"! ... t = nan while running MODE on some data.

I'm calling MODE using the command:

bin/mode \
remap_GOES-16.20190515.220000.nc \
core_mp2_20190515_0000_f22.nc \
core_mp2_2019051500_22_mode_config_file \
-outdir /ships19/models/sarahm/SAR-FV3/mode//2019051500/core_mp2/ \
-v 4

I am been able to process MODE using remap_GOES-16.20190515.220000.nc 
and another file, so I don't think that is the issue. I checked the data 
in core_mp2_20190515_0000_f22.nc, but I couldn't find any obvious errors.

I've uploaded the data to 
ftp.rap.ucar.edu:incoming/irap/met_help/griffin_data/.

Thanks!
Sarah

-- 
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------




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

Subject: PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: John Halley Gotway
Time: Mon Oct 07 14:19:59 2019

Sarah,

Thanks for sending your sample data.  I was able to replicate the
behavior
you describe, but it took almost 15 minutes to do so, processing 105
(196)
simple fcst (obs) objects.

One thing I noticed right away is the value you've chosen for
censoring
data (9999).  MET's internal bad data value is stored as -9999.  So
I'd
suggest using a negative sign in the config file, like this:
   censor_thresh     = [<=0];
   censor_val        = [-9999];
However, there are actually no values which meet that threshold
criteria
anyway:
DEBUG 3: Censored values for 0 of 1814400 grid points.

While debugging, I turned off the requested matching by setting:
match_flag
= NONE;

But that yields this runtime error:
ERROR  : check_hdr_str() -> output header column value ("top of
atmosphere") should contain no embedded whitespace!

MET is reading the level attribute from core_mp2_20190515_0000_f22.nc,
and
is trying to write it to the OBS_LEV output column.  But MET errors
out
because no embedded whitespace is allowed in the output ASCII files.
I'm
wondering what you'd like to software to do in this case?  Should it
just
tell you about the problem and let you fix it?  Or should it
automatically
replace whitespace with underscores?

Thanks,
John




On Mon, Oct 7, 2019 at 11:41 AM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:

>
> Mon Oct 07 11:41:03 2019: Request 92478 was acted upon.
> Transaction: Ticket created by sarah.griffin at ssec.wisc.edu
>        Queue: met_help
>      Subject: PiecewiseLinear::operator()(double) -> error in
> "aspect_diff"! ... t = nan
>        Owner: Nobody
>   Requestors: sarah.griffin at ssec.wisc.edu
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=92478 >
>
>
> Hi,
>
> I'm getting the error PiecewiseLinear::operator()(double) -> error
in
> "aspect_diff"! ... t = nan while running MODE on some data.
>
> I'm calling MODE using the command:
>
> bin/mode \
> remap_GOES-16.20190515.220000.nc \
> core_mp2_20190515_0000_f22.nc \
> core_mp2_2019051500_22_mode_config_file \
> -outdir /ships19/models/sarahm/SAR-FV3/mode//2019051500/core_mp2/ \
> -v 4
>
> I am been able to process MODE using remap_GOES-
16.20190515.220000.nc
> and another file, so I don't think that is the issue. I checked the
data
> in core_mp2_20190515_0000_f22.nc, but I couldn't find any obvious
errors.
>
> I've uploaded the data to
> ftp.rap.ucar.edu:incoming/irap/met_help/griffin_data/.
>
> Thanks!
> Sarah
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #92478] PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: Sarah Griffin
Time: Mon Oct 07 14:42:44 2019

Hi John,

Yes, it takes a while to process all of the objects.

I've added another file, core_mp1_20190515_0000_f22.nc, to my data
directory, in case it is useful. This file runs fine in MODE paired
with
remap_GOES-16.20190515.220000.nc.

As for the whitespace, I don't know what the answer is. I'd just like
to
get MODE to work. Is the whitespace the issue or is there something
else? The attributes between the core files appear to be the same, yet
one works and another one doesn't.

Have a great day!
Sarah

On 10/7/19 3:19 PM, John Halley Gotway via RT wrote:
> Sarah,
>
> Thanks for sending your sample data.  I was able to replicate the
behavior
> you describe, but it took almost 15 minutes to do so, processing 105
(196)
> simple fcst (obs) objects.
>
> One thing I noticed right away is the value you've chosen for
censoring
> data (9999).  MET's internal bad data value is stored as -9999.  So
I'd
> suggest using a negative sign in the config file, like this:
>     censor_thresh     = [<=0];
>     censor_val        = [-9999];
> However, there are actually no values which meet that threshold
criteria
> anyway:
> DEBUG 3: Censored values for 0 of 1814400 grid points.
>
> While debugging, I turned off the requested matching by setting:
match_flag
> = NONE;
>
> But that yields this runtime error:
> ERROR  : check_hdr_str() -> output header column value ("top of
> atmosphere") should contain no embedded whitespace!
>
> MET is reading the level attribute from
core_mp2_20190515_0000_f22.nc, and
> is trying to write it to the OBS_LEV output column.  But MET errors
out
> because no embedded whitespace is allowed in the output ASCII files.
I'm
> wondering what you'd like to software to do in this case?  Should it
just
> tell you about the problem and let you fix it?  Or should it
automatically
> replace whitespace with underscores?
>
> Thanks,
> John
>
>
>
>
> On Mon, Oct 7, 2019 at 11:41 AM Sarah Griffin via RT
<met_help at ucar.edu>
> wrote:
>
>> Mon Oct 07 11:41:03 2019: Request 92478 was acted upon.
>> Transaction: Ticket created by sarah.griffin at ssec.wisc.edu
>>         Queue: met_help
>>       Subject: PiecewiseLinear::operator()(double) -> error in
>> "aspect_diff"! ... t = nan
>>         Owner: Nobody
>>    Requestors: sarah.griffin at ssec.wisc.edu
>>        Status: new
>>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=92478 >
>>
>>
>> Hi,
>>
>> I'm getting the error PiecewiseLinear::operator()(double) -> error
in
>> "aspect_diff"! ... t = nan while running MODE on some data.
>>
>> I'm calling MODE using the command:
>>
>> bin/mode \
>> remap_GOES-16.20190515.220000.nc \
>> core_mp2_20190515_0000_f22.nc \
>> core_mp2_2019051500_22_mode_config_file \
>> -outdir /ships19/models/sarahm/SAR-FV3/mode//2019051500/core_mp2/ \
>> -v 4
>>
>> I am been able to process MODE using remap_GOES-
16.20190515.220000.nc
>> and another file, so I don't think that is the issue. I checked the
data
>> in core_mp2_20190515_0000_f22.nc, but I couldn't find any obvious
errors.
>>
>> I've uploaded the data to
>> ftp.rap.ucar.edu:incoming/irap/met_help/griffin_data/.
>>
>> Thanks!
>> Sarah
>>
>> --
>>
>>
----------------------------------------------------------------------------
>> Sarah M. Griffin
>> Associate Research Scientist
>> Cooperative Institute for Meteorological Satellite Studies / SSEC
>> UW-Madison
>> 1225 W Dayton St. Rm 243
>> Madison, WI 53706
>> sarah.griffin at ssec.wisc.edu
>> (608) 262-0986
>>
>>
----------------------------------------------------------------------------
>>
>>
>>
>>


--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------



------------------------------------------------
Subject: PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: John Halley Gotway
Time: Tue Oct 08 13:14:32 2019

Hi Sarah,

Thanks for sending that additional data.  I've handed this issue off
to
Randy Bullock, the primary developer of MODE.  And he'll get in touch
with
you.

Thanks,
John

On Mon, Oct 7, 2019 at 2:43 PM Sarah Griffin via RT
<met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=92478 >
>
> Hi John,
>
> Yes, it takes a while to process all of the objects.
>
> I've added another file, core_mp1_20190515_0000_f22.nc, to my data
> directory, in case it is useful. This file runs fine in MODE paired
with
> remap_GOES-16.20190515.220000.nc.
>
> As for the whitespace, I don't know what the answer is. I'd just
like to
> get MODE to work. Is the whitespace the issue or is there something
> else? The attributes between the core files appear to be the same,
yet
> one works and another one doesn't.
>
> Have a great day!
> Sarah
>
> On 10/7/19 3:19 PM, John Halley Gotway via RT wrote:
> > Sarah,
> >
> > Thanks for sending your sample data.  I was able to replicate the
> behavior
> > you describe, but it took almost 15 minutes to do so, processing
105
> (196)
> > simple fcst (obs) objects.
> >
> > One thing I noticed right away is the value you've chosen for
censoring
> > data (9999).  MET's internal bad data value is stored as -9999.
So I'd
> > suggest using a negative sign in the config file, like this:
> >     censor_thresh     = [<=0];
> >     censor_val        = [-9999];
> > However, there are actually no values which meet that threshold
criteria
> > anyway:
> > DEBUG 3: Censored values for 0 of 1814400 grid points.
> >
> > While debugging, I turned off the requested matching by setting:
> match_flag
> > = NONE;
> >
> > But that yields this runtime error:
> > ERROR  : check_hdr_str() -> output header column value ("top of
> > atmosphere") should contain no embedded whitespace!
> >
> > MET is reading the level attribute from
core_mp2_20190515_0000_f22.nc,
> and
> > is trying to write it to the OBS_LEV output column.  But MET
errors out
> > because no embedded whitespace is allowed in the output ASCII
files.  I'm
> > wondering what you'd like to software to do in this case?  Should
it just
> > tell you about the problem and let you fix it?  Or should it
> automatically
> > replace whitespace with underscores?
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Mon, Oct 7, 2019 at 11:41 AM Sarah Griffin via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> Mon Oct 07 11:41:03 2019: Request 92478 was acted upon.
> >> Transaction: Ticket created by sarah.griffin at ssec.wisc.edu
> >>         Queue: met_help
> >>       Subject: PiecewiseLinear::operator()(double) -> error in
> >> "aspect_diff"! ... t = nan
> >>         Owner: Nobody
> >>    Requestors: sarah.griffin at ssec.wisc.edu
> >>        Status: new
> >>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=92478
> >
> >>
> >>
> >> Hi,
> >>
> >> I'm getting the error PiecewiseLinear::operator()(double) ->
error in
> >> "aspect_diff"! ... t = nan while running MODE on some data.
> >>
> >> I'm calling MODE using the command:
> >>
> >> bin/mode \
> >> remap_GOES-16.20190515.220000.nc \
> >> core_mp2_20190515_0000_f22.nc \
> >> core_mp2_2019051500_22_mode_config_file \
> >> -outdir /ships19/models/sarahm/SAR-FV3/mode//2019051500/core_mp2/
\
> >> -v 4
> >>
> >> I am been able to process MODE using remap_GOES-
16.20190515.220000.nc
> >> and another file, so I don't think that is the issue. I checked
the data
> >> in core_mp2_20190515_0000_f22.nc, but I couldn't find any obvious
> errors.
> >>
> >> I've uploaded the data to
> >> ftp.rap.ucar.edu:incoming/irap/met_help/griffin_data/.
> >>
> >> Thanks!
> >> Sarah
> >>
> >> --
> >>
> >>
>
----------------------------------------------------------------------------
> >> Sarah M. Griffin
> >> Associate Research Scientist
> >> Cooperative Institute for Meteorological Satellite Studies / SSEC
> >> UW-Madison
> >> 1225 W Dayton St. Rm 243
> >> Madison, WI 53706
> >> sarah.griffin at ssec.wisc.edu
> >> (608) 262-0986
> >>
> >>
>
----------------------------------------------------------------------------
> >>
> >>
> >>
> >>
>
>
> --
>
>
----------------------------------------------------------------------------
> Sarah M. Griffin
> Associate Research Scientist
> Cooperative Institute for Meteorological Satellite Studies / SSEC
> UW-Madison
> 1225 W Dayton St. Rm 243
> Madison, WI 53706
> sarah.griffin at ssec.wisc.edu
> (608) 262-0986
>
>
----------------------------------------------------------------------------
>
>
>
>

------------------------------------------------
Subject: PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: John Halley Gotway
Time: Wed Nov 06 16:59:23 2019

Randy,

This is a ticket from October 8th.  It looks like I failed to assign
it to you when I intended to.  Are you able to check in with Sarah
Griffin about this issue?

Thanks,
John

------------------------------------------------
Subject: PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: John Halley Gotway
Time: Fri Nov 15 10:36:02 2019

Sarah,

I apologize for LONG delay in getting back to you on this issue you
found.  Randy Bullock, the engineer who developed MODE, ran this case
through the debugger and found that this error occurs when comparing
objects with an area of 1.

For those objects, the length and width are computed as 0, leading to
an aspect ratio of 0/0 = nan.  We haven't run into this situation
before since we almost always throw out tiny objects using an area
threshold.

Long term, we need to fix the code to better handle objects with an
area of 1.  Short term, you can easily get around this problem by
discarding them by setting the following in the MODE config file:
   area_thresh = >1;

I reran the case you sent with/without this setting.  I got the nan
error without it, but confirmed that it did get past that error with
area_thresh = >1.

It did still error out with:
ERROR  : check_hdr_str() -> output header column value ("top of
atmosphere") should contain no embedded whitespace!


For met-9.0, we could change that error to a warning and automatically
replace spaces with underscores.  Does that sound like the right fix?

Thanks,
John Halley Gotway

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #92478] PiecewiseLinear::operator()(double) -> error in "aspect_diff"! ... t = nan
From: Sarah Griffin
Time: Tue Nov 19 08:35:56 2019

Thanks John! Now it works just fine.

On 11/15/19 11:36 AM, John Halley Gotway via RT wrote:
> Sarah,
>
> I apologize for LONG delay in getting back to you on this issue you
found.  Randy Bullock, the engineer who developed MODE, ran this case
through the debugger and found that this error occurs when comparing
objects with an area of 1.
>
> For those objects, the length and width are computed as 0, leading
to an aspect ratio of 0/0 = nan.  We haven't run into this situation
before since we almost always throw out tiny objects using an area
threshold.
>
> Long term, we need to fix the code to better handle objects with an
area of 1.  Short term, you can easily get around this problem by
discarding them by setting the following in the MODE config file:
>     area_thresh = >1;
>
> I reran the case you sent with/without this setting.  I got the nan
error without it, but confirmed that it did get past that error with
area_thresh = >1.
>
> It did still error out with:
> ERROR  : check_hdr_str() -> output header column value ("top of
atmosphere") should contain no embedded whitespace!
>
>
> For met-9.0, we could change that error to a warning and
automatically replace spaces with underscores.  Does that sound like
the right fix?
>
> Thanks,
> John Halley Gotway


--
----------------------------------------------------------------------------
Sarah M. Griffin
Associate Research Scientist
Cooperative Institute for Meteorological Satellite Studies / SSEC UW-
Madison
1225 W Dayton St. Rm 243
Madison, WI 53706
sarah.griffin at ssec.wisc.edu
(608) 262-0986
----------------------------------------------------------------------------



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


More information about the Met_help mailing list