[Met_help] Clarification on data ingest by the MODE tool (METv2.0)

[John Halley Gotway]

Matthew,

You don't need to cut it in half along a longitude yourself.  I was just
pointing out the fact that you already knew about - objects straddling the
prime meridian will be split in two.  That's all I was pointing out.

I believe the answer to your question about expanding by 50 degrees is no,
the code couldn't handle that.  I can't be sure without playing with a
sample data file, but I think we'd get an error in the subroutine that
converts lat/lon's to x/y values.  Since there would be duplicate
lat/lon's on the edges, the x/y values wouldn't be well-defined.

I'm not sure exactly what you're studying, but what other people have done
in the past is chosen a longitude value that isn't very interesting for
their problem - perhaps the center of the pacific if you're studying
land-based phenomena, or the center or africa if you're studying
water-based phenomena.  Then, you could use the copygb tool to regrid the
data from NCEP Grid 003 to one you define that wraps at the longitude you
select rather than the prime meridian.

Another option would be to use the copygb tool to regrid the data into
several smaller grids - perhaps a polar stereographic one for the northern
hemisphere and another one for the southern hemisphere.  Run MODE on all
the subdomains, and try to aggregate the results.

But how you attack this problem really depends on what you're investigating.

Hope that helps.

John

> Thanks for the quick reply.  This confirms my basic understanding that
> distance calculations are in grid box counts within the tool itself...and
> that I'm going to run into a big problem near the poles where the dx
> between
> two longitudes begins to shrink considerably (which will have the affect
> of
> rapidly increasing the "importance" of objects at polar latitudes.
>
> Now I am curious...why does a circumpolar grid need to be split in half by
> longitude?  I was going to run into the problem of split objects anyway
> even
> without cutting the planet in half (because an object crossing the prime
> meridian goes out the right hand side and back into the left hand side so
> may appear to be two objects)...my proposed solution to this problem would
> be falsely expand the grid by adding (say) 50 degrees of duplicated data
> to
> one side or the other (instead of going -180 to 0, perhaps go -180 to 50)
> and when I later process the objects, throw out duplicates.  Can the
> program
> read in a data set like that, though?  Stretching beyond the 180 degree
> limit?
>
> On 1/27/10, John Halley Gotway <johnhg at ucar.edu> wrote:
>>
>> Matthew,
>>
>> It sounds to me like there's a few questions here...
>>
>> (1) How does MODE handle distances between grid points?
>>
>> MODE does all it's computations in the grid units, not actual physical
>> distances.  So the area of an object is just a count of the grid boxes
>> which
>> comprise it.  And the distance between two objects
>> is just a count of grid units between the centers of the objects.  The
>> parameter you're seeing in the configuration file "grid_res" actually
>> isn't
>> used all that much.  Actually, the only place it's
>> used is further down in the configuration file to set reasonable
>> defaults
>> for other parameters.  But you could read about those other parameters
>> and
>> set them how you'd like.
>>
>> (2) What type of projections can the MET tools read?
>>
>> MODE (as well of the other MET tools) can read data that's on lat/lon,
>> lambert conformal, polar stereographic, or mercator projections.  It
>> sounds
>> like your data is on a global lat/lon projection,
>> which may work.  There are a couple of big issues with this though.
>> First,
>> the size of each grid box on a global lat/lon grid will vary
>> considerably.  However, MODE will count them all the same.
>> Depending on your data, if you want to treat objects near the poles the
>> same as objects nears the equator, this will be problematic.  Second,
>> you'll
>> need to choose a longitude at which to cut the grid
>> in half - perhaps the prime meridian for example.  But if you have an
>> object that straddles that line, MODE will treat it as two separate
>> objects.  It isn't set up to handle true global data in that way.
>>
>> I'm guessing the NCEP/NCAR reanalysis 1.0x1.0 degree GFS data is on NCEP
>> Grid 3: http://www.nco.ncep.noaa.gov/pmb/docs/on388/grids/grid003.gif
>> If that's the case, MODE should be able to read data on that grid.
>>
>> (3) What data format should I use?
>>
>> You should use GRIB.  That'd be easiest.  And I'm guessing you'd be able
>> to
>> get this data in GRIB format.
>>
>> Hope that helps.  Please let us know if more questions come up, and if
>> you're having difficulty, feel free to send some sample data files and
>> your
>> MODE config file, and we'd be happy to take a look.
>>
>> Thanks,
>> John Halley Gotway
>> johnhg at ucar.edu
>>
>>
>> Matthew Souders wrote:
>> > I am seeking a bit of clarification about how exactly the MODE tool
>> ingests
>> > gridded data and accounts for distances between grid points. My data
>> sets
>> > are both regular lat/lon grids (not regular dx/dy with constant
>> spacing)
>> and
>> > have global coverage (not a region like the WRF might)...I am working
>> with
>> > NCEP/NCAR Reanalysis and GFS forecast fields from the archived 1.0X1.0
>> > degree grids. I need to know whether MODE can correctly interpret real
>> > distances from GRIB files in regular lat/lon format or whether I'd
>> somehow
>> > need to convert regular lat/lon to regular dx/dy (a process which
>> would
>> be
>> > impossible if I were covering the entire globe since dx changes with
>> > increasing latitude).
>> >
>> >>From what I can tell from the User's Guide for METv2.0, I can use any
>> > gridded data, but I have to make some kind of rough estimate as to the
>> > typical grid spacing. But lat/lon grids aren't regularly spaced enough
>> for
>> > that to make sense. Any clarification you might be able to provide on
>> how
>> > best to work with globally-covering regular lat/lon grids would be
>> > appreciated.
>> >
>> > Matthew Souders
>> > Stony Brook University
>> > School of Marine and Atmospheric Sciences
>> >
>> >
>> >
>>
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Met_help mailing list
>> > Met_help at mailman.ucar.edu
>> > http://mailman.ucar.edu/mailman/listinfo/met_help
>>
>