Chris,
On Tue, 18 Mar 2008, patrick wrote:
a quick glance at your problem has shown me
a few things...
1. you have an abundance of carriage return and line
feed pairs in your data... this is not a good thing.. if
editing off box always ensure to rectify this problem
before attempting manipulation of any kind.
2. if you are unsure how to do the above an easy
fix is to use 'dos2unix' a little snippet designed
for just such a thing... have your admin install
or if you are the admin the package is often
called 'tofrodos'
on a debian box to do so:
su
aptitude update
aptitude install tofrodos
exit
dos2unix test.data
3. yesterday i mentioned to look at the following
http://www.unidata.ucar.edu/cgi-bin/gempak/manual/programs_index?gdedit
note once again the header information.. does this match your file?
gempak is a tab-happy app.. ensure the naming conventions and
locations are within tabbed settings.. this is best done onbox
instead of dumping over as conversions are never perfect.
4. proper dattim format in gempak and especially gdedit is YYMMDD/HHNN
5. on the issue of compiling, for most uses it is not necessary, however
i can only speak from a debian perspective... it is important to ensure
you are using the last chiz build as many of the limits were removed
in the last few versions.
This is a good point... I'm remembering too that recent versions of gempak
were supposed to use dynamic memory allocation for grid arrays which would
make my suggestion of rebuilding with the larger parameters unnecessary...
at least that would be true in theory. I'd follow Patrick's suggestion
for using the latest binary. If that fails, I'd try reducing your grid
dimension to a small size you know will work without any gempak
modifications. If that fails, then you need to focus on your edit file
specifications. If that works but larger grids don't, then there may be
an issue with gempak.
Art
