[Met_help] [rt.rap.ucar.edu #45570] History for MODE error "too many cells"
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Fri Jun 17 14:13:53 MDT 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Dear Met-Help
I am using a rather large ensemble dataset and running MODE.
I encountered an issue where MODE was finding more than 500 objects per time period. I found the max_singles variable in the vx_wrfdata.h file in order to increase the number of objects found.
I reprocessed my data only to get this error:
ERROR: void Partition::add() -> too many cells!
Before I re reprocess my data, what exactly is this error telling me?
I see that max_cells is set to 1000, but there is also max_cell_elements. Do both of these need to be increased?
Is there code I can write to print out what I should set these values too, like the max_singles error yields? For reference here is what max_singles error displays:
ERROR: Engine::do_no_match() -> too many shapes ... increase "max_singles" to at least 532
Just for some background I am processing 1 hour WRF precipitation on a grid of 693 by 863, using a threshold of 1 mm. The time periods giving me the error have large areas of precipitation.
Thanks for any insight you can provide.
James Correia Jr
OU CIMMS Research Associate
SPC HWT Liaison
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: John Halley Gotway
Time: Thu Mar 24 10:39:26 2011
James,
We could approach this problem from two different directions. Either,
I could help you figure out how to modify the code to accommodate the
processing of 500+ objects in your domain, or we could
instead look at how you have MODE configured and see if the
configuration file you're using is really answering the scientific
question you're investigating.
If we did modify the code to handle this very large number of objects,
I think you'd find that the execution time would be exceedingly slow.
Keep in mind that MODE does pairwise comparisons of
forecast/observation objects. If you have 500 objects in each field,
that'd be up to 250,000 pairwise comparisons! And that would take a
lot of processing power.
So I'd recommend taking the second approach. One thing to ask
yourself is, what physical phenomenon are you trying to represent
using the MODE approach? In many applications of MODE to precip data,
we configure MODE to look at larger mescoscale systems. Those setting
usually yield about 0 to 20 objects in each field. However, the
convective weather group at NCAR configures MODE to look at
smaller convective cells. Their configurations yield up to about 100
objects in each field... and their run times are much worse because of
it.
I'd suggest choosing a single MODE case and rerunning it may times,
changing the configuration settings, and observing how it affects the
scale of the objects defined. Your goal should be to find
settings that produce objects which represent the scale of the
physical phenomenon you're studying. In this process, you'd be
tweaking the settings for:
- The convolution, or smoothing, radius: fcst/obs_conv_radius.
- The convolution threshold: fcst/obs_conv_thresh.
In particular, try increasing the convolution radius to smooth
together a bunch of the tiny precip objects into a larger, smoother
one.
After you've chosen the scale of the objects you're after, you could
consider filtering out and discarding the objects in which you are not
interested. In this process, you'd be tweaking the settings
for:
- The object area criteria: fcst/obs_area_thresh. For example, you
could throw out objects that consist of only a few pixels.
- The object intensity criteria: fcst/obs_inten_prec and
fcst/obs_inten_perc_thresh. You might choose to discard objects that
don't meet some intensity criteria.
If, after this process, you would like more advice on applying MODE to
your dataset, I'd be happy to take a look. You can send me a sample
forecast file, observation file, and your MODE config file.
And you could post this data to our anonymous ftp site
(http://www.dtcenter.org/met/users/support/met_help.php#ftp).
I'm doubtful that MODE will run well with 500+ objects in each field
and that the results would be very meaningful. But if it really is
something you'd like to pursue, I'd be happy to help you figure
out how to modify the code to accommodate it. Just let me know how
you'd like to proceed.
Hope that helps.
John Halley Gotway
met_help at ucar.edu
On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
> I reprocessed my data only to get this error:
------------------------------------------------
Subject: MODE error "too many cells"
From: James.Correia
Time: Thu Mar 24 11:11:17 2011
Hi John-
Thanks for taking the time to help. I should provide some more
background.
I am using MODE in a forecast setting only in order to decrease
processing time of our model forecasts. In this case I trick MODE and
feed it 2 hour forecast hours, in the forecast and obs slots. I turned
off the match and merge features so it is strictly doing only the
object id and characteristics.
I am doing this because I want to provide forecasters a summary plot
of object counts by ensemble member so they can attempt to identify
outliers, or trends in the number of precipitation objects.
I have some serious testing of the knobs and buttons in the MODE
config file, changing the threshold, convolution threshold, areas,
etc. I decided that I want to retain even small objects so that our
convection allowing ensemble members are also giving us information on
convection initiation. This is not ideal for me, however, because I
really want the small scale details no matter the computational cost.
In fact I am unhappy with choosing thresholds since our models are
giving us very detailed information and the threshold I choose always
misses something. At some point, I want to use some extra filtering to
get around using only the magntiude of the forecast field, and instead
use the relative magnitude, so more specific features can be detected.
But that is research for another day!
So, the threshold of 1 mm was a compromise, because testing at 0.254
mm yields computation time that will not work in pseudo real time for
my project. 1 mm seems to work well for the statistics I want to
generate from the output.
So, the max_cells and max-cell_elements variables: What do they
actually represent?
For extra context, I have attached an NCL plot of the object counts
over the domain. The ensemble members are on the y-axis and time is
the x-axis. Object counts are shaded.
James Correia Jr
OU CIMMS Research Associate
SPC HWT Liaison
----- Original Message -----
From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
Date: Thursday, March 24, 2011 11:39 am
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> James,
>
> We could approach this problem from two different directions.
> Either, I could help you figure out how to modify the code to
> accommodate the processing of 500+ objects in your domain, or we
could
> instead look at how you have MODE configured and see if the
> configuration file you're using is really answering the scientific
> question you're investigating.
>
> If we did modify the code to handle this very large number of
> objects, I think you'd find that the execution time would be
> exceedingly slow. Keep in mind that MODE does pairwise comparisons
of
> forecast/observation objects. If you have 500 objects in each
> field, that'd be up to 250,000 pairwise comparisons! And that
> would take a lot of processing power.
>
> So I'd recommend taking the second approach. One thing to ask
> yourself is, what physical phenomenon are you trying to represent
> using the MODE approach? In many applications of MODE to precip
data,
> we configure MODE to look at larger mescoscale systems. Those
> setting usually yield about 0 to 20 objects in each field.
> However, the convective weather group at NCAR configures MODE to
> look at
> smaller convective cells. Their configurations yield up to about
> 100 objects in each field... and their run times are much worse
> because of it.
>
> I'd suggest choosing a single MODE case and rerunning it may times,
> changing the configuration settings, and observing how it affects
> the scale of the objects defined. Your goal should be to find
> settings that produce objects which represent the scale of the
> physical phenomenon you're studying. In this process, you'd be
> tweaking the settings for:
> - The convolution, or smoothing, radius: fcst/obs_conv_radius.
> - The convolution threshold: fcst/obs_conv_thresh.
> In particular, try increasing the convolution radius to smooth
> together a bunch of the tiny precip objects into a larger, smoother
> one.
> After you've chosen the scale of the objects you're after, you
> could consider filtering out and discarding the objects in which
> you are not interested. In this process, you'd be tweaking the
> settingsfor:
> - The object area criteria: fcst/obs_area_thresh. For example,
> you could throw out objects that consist of only a few pixels.
> - The object intensity criteria: fcst/obs_inten_prec and
> fcst/obs_inten_perc_thresh. You might choose to discard objects
> that don't meet some intensity criteria.
>
> If, after this process, you would like more advice on applying MODE
> to your dataset, I'd be happy to take a look. You can send me a
> sample forecast file, observation file, and your MODE config file.
> And you could post this data to our anonymous ftp site
> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
> I'm doubtful that MODE will run well with 500+ objects in each
> field and that the results would be very meaningful. But if it
> really is something you'd like to pursue, I'd be happy to help you
> figureout how to modify the code to accommodate it. Just let me
> know how you'd like to proceed.
>
> Hope that helps.
>
> John Halley Gotway
> met_help at ucar.edu
>
> On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
> > I reprocessed my data only to get this error:
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: John Halley Gotway
Time: Thu Mar 24 14:11:36 2011
James,
Cool, that plot looks interesting. As long as you know what you're
doing, I'm happy to help resolve the software issue.
One other trick you could consider would be submitting just a field of
all zeros as the observation. And just pass that in each time. Then
set the "obs_conv_radius = 0" so it doesn't waste time
convolving a bunch of zeros. Perhaps that'd simplify the logic of
your scripts so that all you'd have in the output file is the objects
for that single forecast field.
And you could consider using command line options to disable some of
the MODE output:
"-plot" disables plotting (optional).
"-obj_plot" disables the output of the object split and cluster
fields to a NetCDF file (optional).
"-ct_stat" disables the output of the contingency table standard
statistics file (optional).
That may speed up the runtime slightly and would certainly reduce the
output storage requirements.
For debugging the error you're encountering, it'd be easiest for me to
work with one of your cases. Please send me a sample forecast file
and the configuration file you're using. You can post them
to our anonymous ftp site following these instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Thanks,
John
On 03/24/2011 11:11 AM, RAL HelpDesk {for James.Correia} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
>
> Hi John-
> Thanks for taking the time to help. I should provide some more
background.
> I am using MODE in a forecast setting only in order to decrease
processing time of our model forecasts. In this case I trick MODE and
feed it 2 hour forecast hours, in the forecast and obs slots. I turned
off the match and merge features so it is strictly doing only the
object id and characteristics.
>
> I am doing this because I want to provide forecasters a summary plot
of object counts by ensemble member so they can attempt to identify
outliers, or trends in the number of precipitation objects.
>
> I have some serious testing of the knobs and buttons in the MODE
config file, changing the threshold, convolution threshold, areas,
etc. I decided that I want to retain even small objects so that our
convection allowing ensemble members are also giving us information on
convection initiation. This is not ideal for me, however, because I
really want the small scale details no matter the computational cost.
In fact I am unhappy with choosing thresholds since our models are
giving us very detailed information and the threshold I choose always
misses something. At some point, I want to use some extra filtering to
get around using only the magntiude of the forecast field, and instead
use the relative magnitude, so more specific features can be detected.
But that is research for another day!
>
> So, the threshold of 1 mm was a compromise, because testing at 0.254
mm yields computation time that will not work in pseudo real time for
my project. 1 mm seems to work well for the statistics I want to
generate from the output.
>
> So, the max_cells and max-cell_elements variables: What do they
actually represent?
>
> For extra context, I have attached an NCL plot of the object counts
over the domain. The ensemble members are on the y-axis and time is
the x-axis. Object counts are shaded.
>
>
> James Correia Jr
> OU CIMMS Research Associate
> SPC HWT Liaison
>
> ----- Original Message -----
> From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
> Date: Thursday, March 24, 2011 11:39 am
> Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
>
>> James,
>>
>> We could approach this problem from two different directions.
>> Either, I could help you figure out how to modify the code to
>> accommodate the processing of 500+ objects in your domain, or we
could
>> instead look at how you have MODE configured and see if the
>> configuration file you're using is really answering the scientific
>> question you're investigating.
>>
>> If we did modify the code to handle this very large number of
>> objects, I think you'd find that the execution time would be
>> exceedingly slow. Keep in mind that MODE does pairwise comparisons
of
>> forecast/observation objects. If you have 500 objects in each
>> field, that'd be up to 250,000 pairwise comparisons! And that
>> would take a lot of processing power.
>>
>> So I'd recommend taking the second approach. One thing to ask
>> yourself is, what physical phenomenon are you trying to represent
>> using the MODE approach? In many applications of MODE to precip
data,
>> we configure MODE to look at larger mescoscale systems. Those
>> setting usually yield about 0 to 20 objects in each field.
>> However, the convective weather group at NCAR configures MODE to
>> look at
>> smaller convective cells. Their configurations yield up to about
>> 100 objects in each field... and their run times are much worse
>> because of it.
>>
>> I'd suggest choosing a single MODE case and rerunning it may times,
>> changing the configuration settings, and observing how it affects
>> the scale of the objects defined. Your goal should be to find
>> settings that produce objects which represent the scale of the
>> physical phenomenon you're studying. In this process, you'd be
>> tweaking the settings for:
>> - The convolution, or smoothing, radius: fcst/obs_conv_radius.
>> - The convolution threshold: fcst/obs_conv_thresh.
>> In particular, try increasing the convolution radius to smooth
>> together a bunch of the tiny precip objects into a larger, smoother
>> one.
>> After you've chosen the scale of the objects you're after, you
>> could consider filtering out and discarding the objects in which
>> you are not interested. In this process, you'd be tweaking the
>> settingsfor:
>> - The object area criteria: fcst/obs_area_thresh. For example,
>> you could throw out objects that consist of only a few pixels.
>> - The object intensity criteria: fcst/obs_inten_prec and
>> fcst/obs_inten_perc_thresh. You might choose to discard objects
>> that don't meet some intensity criteria.
>>
>> If, after this process, you would like more advice on applying MODE
>> to your dataset, I'd be happy to take a look. You can send me a
>> sample forecast file, observation file, and your MODE config file.
>> And you could post this data to our anonymous ftp site
>> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
>> I'm doubtful that MODE will run well with 500+ objects in each
>> field and that the results would be very meaningful. But if it
>> really is something you'd like to pursue, I'd be happy to help you
>> figureout how to modify the code to accommodate it. Just let me
>> know how you'd like to proceed.
>>
>> Hope that helps.
>>
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
>>> I reprocessed my data only to get this error:
>>
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: James.Correia
Time: Fri Mar 25 11:34:15 2011
Hi-
Thanks. I have uploaded my data (pre000.nc and pre001.nc) along with
the Mode Config file I use.
The only other issue is that I changed max_singles to be 1500.
James Correia Jr
OU CIMMS Research Associate
SPC HWT Liaison
----- Original Message -----
From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
Date: Thursday, March 24, 2011 3:11 pm
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> James,
>
> Cool, that plot looks interesting. As long as you know what you're
> doing, I'm happy to help resolve the software issue.
>
> One other trick you could consider would be submitting just a field
> of all zeros as the observation. And just pass that in each time.
> Then set the "obs_conv_radius = 0" so it doesn't waste time
> convolving a bunch of zeros. Perhaps that'd simplify the logic of
> your scripts so that all you'd have in the output file is the
> objects for that single forecast field.
>
> And you could consider using command line options to disable some
> of the MODE output:
> "-plot" disables plotting (optional).
> "-obj_plot" disables the output of the object split and cluster
> fields to a NetCDF file (optional).
> "-ct_stat" disables the output of the contingency table standard
> statistics file (optional).
>
> That may speed up the runtime slightly and would certainly reduce
> the output storage requirements.
>
> For debugging the error you're encountering, it'd be easiest for me
> to work with one of your cases. Please send me a sample forecast
> file and the configuration file you're using. You can post them
> to our anonymous ftp site following these instructions:
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Thanks,
> John
>
>
> On 03/24/2011 11:11 AM, RAL HelpDesk {for James.Correia} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
> >
> > Hi John-
> > Thanks for taking the time to help. I should provide some more
> background.> I am using MODE in a forecast setting only in order to
> decrease processing time of our model forecasts. In this case I
> trick MODE and feed it 2 hour forecast hours, in the forecast and
> obs slots. I turned off the match and merge features so it is
> strictly doing only the object id and characteristics.
> >
> > I am doing this because I want to provide forecasters a summary
> plot of object counts by ensemble member so they can attempt to
> identify outliers, or trends in the number of precipitation objects.
> >
> > I have some serious testing of the knobs and buttons in the MODE
> config file, changing the threshold, convolution threshold, areas,
> etc. I decided that I want to retain even small objects so that our
> convection allowing ensemble members are also giving us information
> on convection initiation. This is not ideal for me, however,
> because I really want the small scale details no matter the
> computational cost. In fact I am unhappy with choosing thresholds
> since our models are giving us very detailed information and the
> threshold I choose always misses something. At some point, I want
> to use some extra filtering to get around using only the magntiude
> of the forecast field, and instead use the relative magnitude, so
> more specific features can be detected. But that is research for
> another day!
> >
> > So, the threshold of 1 mm was a compromise, because testing at
> 0.254 mm yields computation time that will not work in pseudo real
> time for my project. 1 mm seems to work well for the statistics I
> want to generate from the output.
> >
> > So, the max_cells and max-cell_elements variables: What do they
> actually represent?
> >
> > For extra context, I have attached an NCL plot of the object
> counts over the domain. The ensemble members are on the y-axis and
> time is the x-axis. Object counts are shaded.
> >
> >
> > James Correia Jr
> > OU CIMMS Research Associate
> > SPC HWT Liaison
> >
> > ----- Original Message -----
> > From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
> > Date: Thursday, March 24, 2011 11:39 am
> > Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> >
> >> James,
> >>
> >> We could approach this problem from two different directions.
> >> Either, I could help you figure out how to modify the code to
> >> accommodate the processing of 500+ objects in your domain, or we
> could>> instead look at how you have MODE configured and see if the
> >> configuration file you're using is really answering the
> scientific
> >> question you're investigating.
> >>
> >> If we did modify the code to handle this very large number of
> >> objects, I think you'd find that the execution time would be
> >> exceedingly slow. Keep in mind that MODE does pairwise
> comparisons of
> >> forecast/observation objects. If you have 500 objects in each
> >> field, that'd be up to 250,000 pairwise comparisons! And that
> >> would take a lot of processing power.
> >>
> >> So I'd recommend taking the second approach. One thing to ask
> >> yourself is, what physical phenomenon are you trying to
> represent
> >> using the MODE approach? In many applications of MODE to precip
> data,>> we configure MODE to look at larger mescoscale systems.
> Those
> >> setting usually yield about 0 to 20 objects in each field.
> >> However, the convective weather group at NCAR configures MODE to
> >> look at
> >> smaller convective cells. Their configurations yield up to
> about
> >> 100 objects in each field... and their run times are much worse
> >> because of it.
> >>
> >> I'd suggest choosing a single MODE case and rerunning it may
> times,
> >> changing the configuration settings, and observing how it
> affects
> >> the scale of the objects defined. Your goal should be to find
> >> settings that produce objects which represent the scale of the
> >> physical phenomenon you're studying. In this process, you'd be
> >> tweaking the settings for:
> >> - The convolution, or smoothing, radius: fcst/obs_conv_radius.
> >> - The convolution threshold: fcst/obs_conv_thresh.
> >> In particular, try increasing the convolution radius to smooth
> >> together a bunch of the tiny precip objects into a larger,
> smoother
> >> one.
> >> After you've chosen the scale of the objects you're after, you
> >> could consider filtering out and discarding the objects in which
> >> you are not interested. In this process, you'd be tweaking the
> >> settingsfor:
> >> - The object area criteria: fcst/obs_area_thresh. For example,
> >> you could throw out objects that consist of only a few pixels.
> >> - The object intensity criteria: fcst/obs_inten_prec and
> >> fcst/obs_inten_perc_thresh. You might choose to discard objects
> >> that don't meet some intensity criteria.
> >>
> >> If, after this process, you would like more advice on applying
> MODE
> >> to your dataset, I'd be happy to take a look. You can send me a
> >> sample forecast file, observation file, and your MODE config
file.
> >> And you could post this data to our anonymous ftp site
> >> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
> >> I'm doubtful that MODE will run well with 500+ objects in each
> >> field and that the results would be very meaningful. But if it
> >> really is something you'd like to pursue, I'd be happy to help
> you
> >> figureout how to modify the code to accommodate it. Just let me
> >> know how you'd like to proceed.
> >>
> >> Hope that helps.
> >>
> >> John Halley Gotway
> >> met_help at ucar.edu
> >>
> >> On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
> >>> I reprocessed my data only to get this error:
> >>
> >>
> >
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: John Halley Gotway
Time: Fri Mar 25 17:01:04 2011
James,
I took a look at your data and wanted to point out a few things:
- First, for the "APCP" variable you have two somewhat odd variable
attributes defined named "lat2d" and "lon2d". It looks like they're a
list of the lat/lon values for each grid point, but it seems
odd that it's defined as a variable attribute. Do you intend to be
using it this way, or should those really be variables unto
themselves?
- Second, the your NetCDF files are missing variable attributes that
MODE is looking for to figure out the timing information. So it's
using a time of 1970. It's looking for the following time
variable attributes: valid_time_ut, init_time_ut, and accum_time_sec.
The first two are in unix time (seconds since 1/1/1970 and the latter
is an accumulation interval in seconds).
- Third, in the config file, you have:
fcst_raw_thresh = "ge1.";
obs_raw_thresh = "ge1.";
Really, I think you want these set to:
fcst_raw_thresh = "ge0.0";
obs_raw_thresh = "ge0.0";
These serve as an optional filtering step to throw out raw values
that don't meet this criteria. Generally, these shouldn't be used
unless there's a good reason to throw out particular raw data
values. It's the "fcst/obs_conv_thresh" settings that are used to
actually define the objects.
Lastly, I was definitely able to reproduce your problem. I'm trying
to debug it but keep running into a seg fault. I'll continue
debugging the issue next week and will let you know how it goes.
Thanks,
John
On 03/25/2011 11:34 AM, RAL HelpDesk {for James.Correia} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
>
> Hi-
> Thanks. I have uploaded my data (pre000.nc and pre001.nc) along with
the Mode Config file I use.
> The only other issue is that I changed max_singles to be 1500.
>
> James Correia Jr
> OU CIMMS Research Associate
> SPC HWT Liaison
>
> ----- Original Message -----
> From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
> Date: Thursday, March 24, 2011 3:11 pm
> Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
>
>> James,
>>
>> Cool, that plot looks interesting. As long as you know what you're
>> doing, I'm happy to help resolve the software issue.
>>
>> One other trick you could consider would be submitting just a field
>> of all zeros as the observation. And just pass that in each time.
>> Then set the "obs_conv_radius = 0" so it doesn't waste time
>> convolving a bunch of zeros. Perhaps that'd simplify the logic of
>> your scripts so that all you'd have in the output file is the
>> objects for that single forecast field.
>>
>> And you could consider using command line options to disable some
>> of the MODE output:
>> "-plot" disables plotting (optional).
>> "-obj_plot" disables the output of the object split and cluster
>> fields to a NetCDF file (optional).
>> "-ct_stat" disables the output of the contingency table standard
>> statistics file (optional).
>>
>> That may speed up the runtime slightly and would certainly reduce
>> the output storage requirements.
>>
>> For debugging the error you're encountering, it'd be easiest for me
>> to work with one of your cases. Please send me a sample forecast
>> file and the configuration file you're using. You can post them
>> to our anonymous ftp site following these instructions:
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> Thanks,
>> John
>>
>>
>> On 03/24/2011 11:11 AM, RAL HelpDesk {for James.Correia} wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
>>>
>>> Hi John-
>>> Thanks for taking the time to help. I should provide some more
>> background.> I am using MODE in a forecast setting only in order to
>> decrease processing time of our model forecasts. In this case I
>> trick MODE and feed it 2 hour forecast hours, in the forecast and
>> obs slots. I turned off the match and merge features so it is
>> strictly doing only the object id and characteristics.
>>>
>>> I am doing this because I want to provide forecasters a summary
>> plot of object counts by ensemble member so they can attempt to
>> identify outliers, or trends in the number of precipitation
objects.
>>>
>>> I have some serious testing of the knobs and buttons in the MODE
>> config file, changing the threshold, convolution threshold, areas,
>> etc. I decided that I want to retain even small objects so that our
>> convection allowing ensemble members are also giving us information
>> on convection initiation. This is not ideal for me, however,
>> because I really want the small scale details no matter the
>> computational cost. In fact I am unhappy with choosing thresholds
>> since our models are giving us very detailed information and the
>> threshold I choose always misses something. At some point, I want
>> to use some extra filtering to get around using only the magntiude
>> of the forecast field, and instead use the relative magnitude, so
>> more specific features can be detected. But that is research for
>> another day!
>>>
>>> So, the threshold of 1 mm was a compromise, because testing at
>> 0.254 mm yields computation time that will not work in pseudo real
>> time for my project. 1 mm seems to work well for the statistics I
>> want to generate from the output.
>>>
>>> So, the max_cells and max-cell_elements variables: What do they
>> actually represent?
>>>
>>> For extra context, I have attached an NCL plot of the object
>> counts over the domain. The ensemble members are on the y-axis and
>> time is the x-axis. Object counts are shaded.
>>>
>>>
>>> James Correia Jr
>>> OU CIMMS Research Associate
>>> SPC HWT Liaison
>>>
>>> ----- Original Message -----
>>> From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
>>> Date: Thursday, March 24, 2011 11:39 am
>>> Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
>>>
>>>> James,
>>>>
>>>> We could approach this problem from two different directions.
>>>> Either, I could help you figure out how to modify the code to
>>>> accommodate the processing of 500+ objects in your domain, or we
>> could>> instead look at how you have MODE configured and see if the
>>>> configuration file you're using is really answering the
>> scientific
>>>> question you're investigating.
>>>>
>>>> If we did modify the code to handle this very large number of
>>>> objects, I think you'd find that the execution time would be
>>>> exceedingly slow. Keep in mind that MODE does pairwise
>> comparisons of
>>>> forecast/observation objects. If you have 500 objects in each
>>>> field, that'd be up to 250,000 pairwise comparisons! And that
>>>> would take a lot of processing power.
>>>>
>>>> So I'd recommend taking the second approach. One thing to ask
>>>> yourself is, what physical phenomenon are you trying to
>> represent
>>>> using the MODE approach? In many applications of MODE to precip
>> data,>> we configure MODE to look at larger mescoscale systems.
>> Those
>>>> setting usually yield about 0 to 20 objects in each field.
>>>> However, the convective weather group at NCAR configures MODE to
>>>> look at
>>>> smaller convective cells. Their configurations yield up to
>> about
>>>> 100 objects in each field... and their run times are much worse
>>>> because of it.
>>>>
>>>> I'd suggest choosing a single MODE case and rerunning it may
>> times,
>>>> changing the configuration settings, and observing how it
>> affects
>>>> the scale of the objects defined. Your goal should be to find
>>>> settings that produce objects which represent the scale of the
>>>> physical phenomenon you're studying. In this process, you'd be
>>>> tweaking the settings for:
>>>> - The convolution, or smoothing, radius: fcst/obs_conv_radius.
>>>> - The convolution threshold: fcst/obs_conv_thresh.
>>>> In particular, try increasing the convolution radius to smooth
>>>> together a bunch of the tiny precip objects into a larger,
>> smoother
>>>> one.
>>>> After you've chosen the scale of the objects you're after, you
>>>> could consider filtering out and discarding the objects in which
>>>> you are not interested. In this process, you'd be tweaking the
>>>> settingsfor:
>>>> - The object area criteria: fcst/obs_area_thresh. For example,
>>>> you could throw out objects that consist of only a few pixels.
>>>> - The object intensity criteria: fcst/obs_inten_prec and
>>>> fcst/obs_inten_perc_thresh. You might choose to discard objects
>>>> that don't meet some intensity criteria.
>>>>
>>>> If, after this process, you would like more advice on applying
>> MODE
>>>> to your dataset, I'd be happy to take a look. You can send me a
>>>> sample forecast file, observation file, and your MODE config
file.
>>>> And you could post this data to our anonymous ftp site
>>>> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
>>>> I'm doubtful that MODE will run well with 500+ objects in each
>>>> field and that the results would be very meaningful. But if it
>>>> really is something you'd like to pursue, I'd be happy to help
>> you
>>>> figureout how to modify the code to accommodate it. Just let me
>>>> know how you'd like to proceed.
>>>>
>>>> Hope that helps.
>>>>
>>>> John Halley Gotway
>>>> met_help at ucar.edu
>>>>
>>>> On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
>>>>> I reprocessed my data only to get this error:
>>>>
>>>>
>>>
>>
>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: James.Correia
Time: Tue Apr 05 09:15:31 2011
Hi John-
Any luck on the debugging?
1. The attributes are an artifact from NCL. I have grib data files
that I convert to netcdf to plug in to MODE. The primary reason I do
this is to get the map background to show up, since I figured out what
was going on in netcdf but not grib data. In this case I had to
mulitply the longitude by -1 in the data to get the netcdf data to
display the map background in MODE plots. I never figured out why my
grib data would not plot with the background. I think it is because I
start with gempak files and convert to grib.
2. Thanks for the time information, I have hacked my way aroudn that.
But for this next iteration of the Spring Experiment I will
incorporate the time fixes.
3. I didn't realize what was going on here. I will fix this.
Thanks for all your help, it was much appreciated.
James Correia Jr
OU CIMMS Research Associate
SPC HWT Liaison
----- Original Message -----
From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
Date: Friday, March 25, 2011 6:01 pm
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> James,
>
> I took a look at your data and wanted to point out a few things:
>
> - First, for the "APCP" variable you have two somewhat odd variable
> attributes defined named "lat2d" and "lon2d". It looks like
> they're a list of the lat/lon values for each grid point, but it
seems
> odd that it's defined as a variable attribute. Do you intend to be
> using it this way, or should those really be variables unto
> themselves?
> - Second, the your NetCDF files are missing variable attributes
> that MODE is looking for to figure out the timing information. So
> it's using a time of 1970. It's looking for the following time
> variable attributes: valid_time_ut, init_time_ut, and
> accum_time_sec. The first two are in unix time (seconds since
> 1/1/1970 and the latter is an accumulation interval in seconds).
>
> - Third, in the config file, you have:
> fcst_raw_thresh = "ge1.";
> obs_raw_thresh = "ge1.";
> Really, I think you want these set to:
> fcst_raw_thresh = "ge0.0";
> obs_raw_thresh = "ge0.0";
> These serve as an optional filtering step to throw out raw values
> that don't meet this criteria. Generally, these shouldn't be used
> unless there's a good reason to throw out particular raw data
> values. It's the "fcst/obs_conv_thresh" settings that are used to
> actually define the objects.
>
> Lastly, I was definitely able to reproduce your problem. I'm
> trying to debug it but keep running into a seg fault. I'll
> continue debugging the issue next week and will let you know how it
> goes.
> Thanks,
> John
>
>
> On 03/25/2011 11:34 AM, RAL HelpDesk {for James.Correia} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
> >
> > Hi-
> > Thanks. I have uploaded my data (pre000.nc and pre001.nc) along
> with the Mode Config file I use.
> > The only other issue is that I changed max_singles to be 1500.
> >
> > James Correia Jr
> > OU CIMMS Research Associate
> > SPC HWT Liaison
> >
> > ----- Original Message -----
> > From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
> > Date: Thursday, March 24, 2011 3:11 pm
> > Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> >
> >> James,
> >>
> >> Cool, that plot looks interesting. As long as you know what
> you're
> >> doing, I'm happy to help resolve the software issue.
> >>
> >> One other trick you could consider would be submitting just a
> field
> >> of all zeros as the observation. And just pass that in each
> time.
> >> Then set the "obs_conv_radius = 0" so it doesn't waste time
> >> convolving a bunch of zeros. Perhaps that'd simplify the logic
> of
> >> your scripts so that all you'd have in the output file is the
> >> objects for that single forecast field.
> >>
> >> And you could consider using command line options to disable
> some
> >> of the MODE output:
> >> "-plot" disables plotting (optional).
> >> "-obj_plot" disables the output of the object split and cluster
> >> fields to a NetCDF file (optional).
> >> "-ct_stat" disables the output of the contingency table standard
> >> statistics file (optional).
> >>
> >> That may speed up the runtime slightly and would certainly
> reduce
> >> the output storage requirements.
> >>
> >> For debugging the error you're encountering, it'd be easiest for
> me
> >> to work with one of your cases. Please send me a sample
> forecast
> >> file and the configuration file you're using. You can post them
> >> to our anonymous ftp site following these instructions:
> >> http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> On 03/24/2011 11:11 AM, RAL HelpDesk {for James.Correia} wrote:
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
> >>>
> >>> Hi John-
> >>> Thanks for taking the time to help. I should provide some more
> >> background.> I am using MODE in a forecast setting only in order
> to
> >> decrease processing time of our model forecasts. In this case I
> >> trick MODE and feed it 2 hour forecast hours, in the forecast
> and
> >> obs slots. I turned off the match and merge features so it is
> >> strictly doing only the object id and characteristics.
> >>>
> >>> I am doing this because I want to provide forecasters a summary
> >> plot of object counts by ensemble member so they can attempt to
> >> identify outliers, or trends in the number of precipitation
> objects.>>>
> >>> I have some serious testing of the knobs and buttons in the
> MODE
> >> config file, changing the threshold, convolution threshold,
> areas,
> >> etc. I decided that I want to retain even small objects so that
> our
> >> convection allowing ensemble members are also giving us
> information
> >> on convection initiation. This is not ideal for me, however,
> >> because I really want the small scale details no matter the
> >> computational cost. In fact I am unhappy with choosing
> thresholds
> >> since our models are giving us very detailed information and the
> >> threshold I choose always misses something. At some point, I
> want
> >> to use some extra filtering to get around using only the
> magntiude
> >> of the forecast field, and instead use the relative magnitude,
> so
> >> more specific features can be detected. But that is research for
> >> another day!
> >>>
> >>> So, the threshold of 1 mm was a compromise, because testing at
> >> 0.254 mm yields computation time that will not work in pseudo
> real
> >> time for my project. 1 mm seems to work well for the statistics
> I
> >> want to generate from the output.
> >>>
> >>> So, the max_cells and max-cell_elements variables: What do they
> >> actually represent?
> >>>
> >>> For extra context, I have attached an NCL plot of the object
> >> counts over the domain. The ensemble members are on the y-axis
> and
> >> time is the x-axis. Object counts are shaded.
> >>>
> >>>
> >>> James Correia Jr
> >>> OU CIMMS Research Associate
> >>> SPC HWT Liaison
> >>>
> >>> ----- Original Message -----
> >>> From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
> >>> Date: Thursday, March 24, 2011 11:39 am
> >>> Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many
cells"
> >>>
> >>>> James,
> >>>>
> >>>> We could approach this problem from two different directions.
> >>>> Either, I could help you figure out how to modify the code to
> >>>> accommodate the processing of 500+ objects in your domain, or
> we
> >> could>> instead look at how you have MODE configured and see if
> the
> >>>> configuration file you're using is really answering the
> >> scientific
> >>>> question you're investigating.
> >>>>
> >>>> If we did modify the code to handle this very large number of
> >>>> objects, I think you'd find that the execution time would be
> >>>> exceedingly slow. Keep in mind that MODE does pairwise
> >> comparisons of
> >>>> forecast/observation objects. If you have 500 objects in each
> >>>> field, that'd be up to 250,000 pairwise comparisons! And that
> >>>> would take a lot of processing power.
> >>>>
> >>>> So I'd recommend taking the second approach. One thing to ask
> >>>> yourself is, what physical phenomenon are you trying to
> >> represent
> >>>> using the MODE approach? In many applications of MODE to
> precip
> >> data,>> we configure MODE to look at larger mescoscale systems.
> >> Those
> >>>> setting usually yield about 0 to 20 objects in each field.
> >>>> However, the convective weather group at NCAR configures MODE
> to
> >>>> look at
> >>>> smaller convective cells. Their configurations yield up to
> >> about
> >>>> 100 objects in each field... and their run times are much
> worse
> >>>> because of it.
> >>>>
> >>>> I'd suggest choosing a single MODE case and rerunning it may
> >> times,
> >>>> changing the configuration settings, and observing how it
> >> affects
> >>>> the scale of the objects defined. Your goal should be to find
> >>>> settings that produce objects which represent the scale of the
> >>>> physical phenomenon you're studying. In this process, you'd
> be
> >>>> tweaking the settings for:
> >>>> - The convolution, or smoothing, radius: fcst/obs_conv_radius.
> >>>> - The convolution threshold: fcst/obs_conv_thresh.
> >>>> In particular, try increasing the convolution radius to smooth
> >>>> together a bunch of the tiny precip objects into a larger,
> >> smoother
> >>>> one.
> >>>> After you've chosen the scale of the objects you're after, you
> >>>> could consider filtering out and discarding the objects in
> which
> >>>> you are not interested. In this process, you'd be tweaking
> the
> >>>> settingsfor:
> >>>> - The object area criteria: fcst/obs_area_thresh. For
> example,
> >>>> you could throw out objects that consist of only a few pixels.
> >>>> - The object intensity criteria: fcst/obs_inten_prec and
> >>>> fcst/obs_inten_perc_thresh. You might choose to discard
> objects
> >>>> that don't meet some intensity criteria.
> >>>>
> >>>> If, after this process, you would like more advice on applying
> >> MODE
> >>>> to your dataset, I'd be happy to take a look. You can send me
> a
> >>>> sample forecast file, observation file, and your MODE config
> file.>>>> And you could post this data to our anonymous ftp site
> >>>> (http://www.dtcenter.org/met/users/support/met_help.php#ftp).
> >>>> I'm doubtful that MODE will run well with 500+ objects in each
> >>>> field and that the results would be very meaningful. But if
> it
> >>>> really is something you'd like to pursue, I'd be happy to help
> >> you
> >>>> figureout how to modify the code to accommodate it. Just let
> me
> >>>> know how you'd like to proceed.
> >>>>
> >>>> Hope that helps.
> >>>>
> >>>> John Halley Gotway
> >>>> met_help at ucar.edu
> >>>>
> >>>> On 03/24/2011 09:47 AM, RAL HelpDesk {for James.Correia} wrote:
> >>>>> I reprocessed my data only to get this error:
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: John Halley Gotway
Time: Tue Apr 05 09:20:23 2011
James,
Not much luck so far on my end. I've looked at it a couple times over
the last week, and when I try to increase the number of allowable
objects to accommodate the data you're using, I end up getting
a segfault. I've run it through the debugger to try to isolate the
problem, but have come up empty so far.
I'll keep working on it and let you know how it goes.
Thanks,
John
On 04/05/2011 09:15 AM, RAL HelpDesk {for James.Correia} wrote:
> from NCL. I have grib data files that I convert to netcdf to plug
in to MODE. The primary reason I do this is to get the map background
to show up, since I figured out what was going on in netcdf but not
grib data. In this case I had to mulitply the longitude by -1 in the
data to get the netcdf data to display the map background in MODE
plots. I never figured out why my grib data would not plot with the
background. I think it is because I start with gempak files and
convert to grib.
>
> 2. Thanks for the time information, I have hacked my way aroudn
that. But for this next iteration of the Spring Experiment I will
incorporate the time fixes.
>
> 3. I didn't realize what was going on here. I will fix this.
>
> Thanks for all your help, it was much appreciated.
------------------------------------------------
Subject: MODE error "too many cells"
From: John Halley Gotway
Time: Wed May 25 12:12:25 2011
James,
Let me start by apologizing for the delay in getting back with you on
this. I've thrashed on this issue off and on for a few weeks trying
to find the reason for the seg fault that arose when trying
to increase the maximum number of cells allowed. I did discover that
if I made use of an existing class from a utility MET library, I could
resolve the seg fault issue. So I've decided to approach
this problem from two directions.
First, I'm sending you some modifications that you can apply to your
build of METv3.0. These changes should allow you to run MODE in the
way you want and generate a whole bunch of objects. I assume
you're using METv3.0 - please let me know if that's not the case. To
apply these changes, you should:
(1) Unpack the METv3.0 release:
http://www.dtcenter.org/met/users/downloads/MET_releases/METv3.0.20100930.tar.gz
(2) Apply the latest set of METv3.0 patches:
http://www.dtcenter.org/met/users/support/known_issues/METv3.0/patches/METv3.0_patches_20110419.tar.gz
> mv METv3.0_patches_20110419.tar.gz METv3.0/.
> tar -xvzf METv3.0_patches_20110419.tar.gz
(3) Apply the patches that I've attached to this message:
> mv METv3.0_patches_correia_20110525.tar.gz METv3.0/.
> tar -xvzf METv3.0_patches_correia_20110525.tar.gz
(4) Compile MET.
Second, I've added a new task to our development effort for the next
release of MET, and that is to clean up the source code to allow for
an arbitrary number of MODE objects. That way we won't run
into these sorts silly upper limits on the numbers of objects.
Please try running METv3.0 using the attached patches and let me know
if this resolves the issues you were having. I ran MODE using a
sample data and config file you sent me a while back. I chose to
use the forecast config file settings to define the forecast objects
you wanted, but set the observation config file settings so that no
objects would be defined. It did run to completion generating
1130 forecast objects but took over 10 minutes to run a single case!
The larger the number of objects, the slower MODE will run. MODE
generally performs better on a smaller number of more mesoscale
type objects, rather than a large number of more convective scale type
objects.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 04/05/2011 09:20 AM, RAL HelpDesk {for John Halley Gotway} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
>
> James,
>
> Not much luck so far on my end. I've looked at it a couple times
over the last week, and when I try to increase the number of allowable
objects to accommodate the data you're using, I end up getting
> a segfault. I've run it through the debugger to try to isolate the
problem, but have come up empty so far.
>
> I'll keep working on it and let you know how it goes.
>
> Thanks,
> John
>
> On 04/05/2011 09:15 AM, RAL HelpDesk {for James.Correia} wrote:
>> from NCL. I have grib data files that I convert to netcdf to plug
in to MODE. The primary reason I do this is to get the map background
to show up, since I figured out what was going on in netcdf but not
grib data. In this case I had to mulitply the longitude by -1 in the
data to get the netcdf data to display the map background in MODE
plots. I never figured out why my grib data would not plot with the
background. I think it is because I start with gempak files and
convert to grib.
>>
>> 2. Thanks for the time information, I have hacked my way aroudn
that. But for this next iteration of the Spring Experiment I will
incorporate the time fixes.
>>
>> 3. I didn't realize what was going on here. I will fix this.
>>
>> Thanks for all your help, it was much appreciated.
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
From: James.Correia
Time: Mon Jun 13 08:37:32 2011
Thanks John-
I am finished with the Hazardous Weather Testbed Experimental Forecast
Program so I will be jumping back into this. I really appreciate your
hard work and will let you know how it goes.
Thanks!
James Correia Jr
OU CIMMS Research Associate
SPC HWT Liaison
----- Original Message -----
From: RAL HelpDesk {for John Halley Gotway} <met_help at ucar.edu>
Date: Wednesday, May 25, 2011 1:12 pm
Subject: Re: [rt.rap.ucar.edu #45570] MODE error "too many cells"
> James,
>
> Let me start by apologizing for the delay in getting back with you
> on this. I've thrashed on this issue off and on for a few weeks
> trying to find the reason for the seg fault that arose when trying
> to increase the maximum number of cells allowed. I did discover
> that if I made use of an existing class from a utility MET library,
> I could resolve the seg fault issue. So I've decided to approach
> this problem from two directions.
>
> First, I'm sending you some modifications that you can apply to
> your build of METv3.0. These changes should allow you to run MODE
> in the way you want and generate a whole bunch of objects. I assume
> you're using METv3.0 - please let me know if that's not the case.
> To apply these changes, you should:
>
> (1) Unpack the METv3.0 release:
>
>
http://www.dtcenter.org/met/users/downloads/MET_releases/METv3.0.20100930.tar.gz
> (2) Apply the latest set of METv3.0 patches:
>
>
http://www.dtcenter.org/met/users/support/known_issues/METv3.0/patches/METv3.0_patches_20110419.tar.gz
> mv METv3.0_patches_20110419.tar.gz METv3.0/.
> > tar -xvzf METv3.0_patches_20110419.tar.gz
>
> (3) Apply the patches that I've attached to this message:
> > mv METv3.0_patches_correia_20110525.tar.gz METv3.0/.
> > tar -xvzf METv3.0_patches_correia_20110525.tar.gz
>
> (4) Compile MET.
>
> Second, I've added a new task to our development effort for the
> next release of MET, and that is to clean up the source code to
> allow for an arbitrary number of MODE objects. That way we won't
run
> into these sorts silly upper limits on the numbers of objects.
>
> Please try running METv3.0 using the attached patches and let me
> know if this resolves the issues you were having. I ran MODE using
> a sample data and config file you sent me a while back. I chose to
> use the forecast config file settings to define the forecast
> objects you wanted, but set the observation config file settings so
> that no objects would be defined. It did run to completion
generating
> 1130 forecast objects but took over 10 minutes to run a single
> case! The larger the number of objects, the slower MODE will run.
> MODE generally performs better on a smaller number of more mesoscale
> type objects, rather than a large number of more convective scale
> type objects.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
> On 04/05/2011 09:20 AM, RAL HelpDesk {for John Halley Gotway} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=45570 >
> >
> > James,
> >
> > Not much luck so far on my end. I've looked at it a couple times
> over the last week, and when I try to increase the number of
> allowable objects to accommodate the data you're using, I end up
> getting> a segfault. I've run it through the debugger to try to
> isolate the problem, but have come up empty so far.
> >
> > I'll keep working on it and let you know how it goes.
> >
> > Thanks,
> > John
> >
> > On 04/05/2011 09:15 AM, RAL HelpDesk {for James.Correia} wrote:
> >> from NCL. I have grib data files that I convert to netcdf to
> plug in to MODE. The primary reason I do this is to get the map
> background to show up, since I figured out what was going on in
> netcdf but not grib data. In this case I had to mulitply the
> longitude by -1 in the data to get the netcdf data to display the
> map background in MODE plots. I never figured out why my grib data
> would not plot with the background. I think it is because I start
> with gempak files and convert to grib.
> >>
> >> 2. Thanks for the time information, I have hacked my way aroudn
> that. But for this next iteration of the Spring Experiment I will
> incorporate the time fixes.
> >>
> >> 3. I didn't realize what was going on here. I will fix this.
> >>
> >> Thanks for all your help, it was much appreciated.
>
>
------------------------------------------------
More information about the Met_help
mailing list