20011106: gempak programming question

Travis,

The GEMPAK storage files are machine dependent. The
MTMACH assignment for the machine type (defined in the
$GEMPAK/include files) that wrote the file is stored in
the file and is needed to determine if byte swapping is
necessary when reading the data.

The MTMACH number for Linux was added in GEMPAK 5.6.b:
eg, GEMPRM.PRM:     PARAMETER       ( MTLNUX =    11   )

Your solaris versions of GEMPAK are both older than this,
so they don't have a mapping for machine type 11.

Upgrade your Solaris distribution of GEMPAK.

Steve Chiswell
Unidata User Support



On Tue, 6 Nov 2001, Travis Smith wrote:

>
> Hello again,
>
> (Is anyone out there?  :-)
>
> I've done some more investigation on my little problem.  As best as
> I can tell, it is not a problem with my program, but possibly with
> the Solaris gempak libraries.
>
> It seems that any gridded data file created on a linux box (PC)
> cannot be read on a Sun.  It can, however, be read under IRIX on
> an SGI.  Instead of using my own program to create a grid file,
> I instead used "gdcfil" to create an empty grid file on the linux
> machine.  Then, I copied it over to a couple of different Suns and
> an SGI.
>
>   PC/linux with GEMPAK 5.6d --> reads file
>   SGI      with GEMPAK 5.6c --> reads file
>   Sun      with GEMAPK 5.4  --> segmentation fault
>   Sun      with GEMPAK 5.6  --> segmentation fault
>
> The backtrace from the error I get when trying to read the file
> under Solaris is as follows:
>
>    GDFILE    Grid file                         $GEMDATA/HRCBOB.GRD
>    LSTALL    Full list flag                    YES
>    OUTPUT    Output device/filename            T
>    Parameters requested: GDFILE,LSTALL,OUTPUT.
>    GEMPAK-GDINFO>gdfile=gdtest.gem
>    GEMPAK-GDINFO>run
>
>   Program received signal SIGSEGV, Segmentation fault.
>   0x1d844 in dm_clos_ ()
>   (gdb) bt
>   #0  0x1d844 in dm_clos_ ()
>   #1  0x1e5c8 in gd_ofil_ ()
>   #2  0x1aa04 in gd_opnf_ ()
>   #3  0x13aa0 in gr_open_ ()
>   #4  0x12f10 in MAIN_ ()
>   #5  0x130a0 in main ()
>
> Has anyone else experienced this?  Is there someone in particular
> I should report this to?
>
> Thanks,
>
> Travis
>
>
> > Travis Smith wrote:
> >
> > > Greetings, all,
> > >
> > > I have written a simple C program that uses gemlib calls to degrade
> > > the resolution of some gridded data and write the data back out
> > > in a new file.  It works just fine under linux, but when I compile
> > > the program under Solaris 2.6 and try to run it on the same input
> > > file, it dies with the following trace:
> > >
> > >   Program received signal SIGSEGV, Segmentation fault.
> > >   0x28468 in mv_swp4_ ()
> > >   (gdb) bt
> > >   #0  0x28468 in mv_swp4_ ()
> > >   #1  0x1ca08 in dm_rint_ ()
> > >   #2  0x2c078 in dm_rdmg_ ()
> > >   #3  0x2b39c in dm_open_ ()
> > >   #4  0x26b00 in gd_ofil_ ()
> > >   Cannot access memory at address 0x8050fb27.
> > >
> > > which seems to be some sort of byte-swapping routing.
> > >
> > > In addition my output file (created under linux) can be read with
> > > no problem under linux, but dies when "gdinfo" tries to read it
> > > under Solaris 2.6:
> > >
> > >   GEMPAK-GDINFO>run
> > >
> > >   Program received signal SIGSEGV, Segmentation fault.
> > >   0x1d844 in dm_clos_ ()
> > >   (gdb) bt
> > >   #0  0x1d844 in dm_clos_ ()
> > >   #1  0x1e5c8 in gd_ofil_ ()
> > >   #2  0x1aa04 in gd_opnf_ ()
> > >   #3  0x13aa0 in gr_open_ ()
> > >   #4  0x12f10 in MAIN_ ()
> > >   #5  0x130a0 in main ()
> > >
> > > I was under the impression that GEMPAK grid files were platform-
> > > independent, but maybe not?  If anyone can help, I'd really
> > > appreciate any pointers you can give.
> > >
> > > On another related note:  is there someplace I can download the
> > > GEMPAK programmer's guide?  I had seen one quite a few years ago,
> > > but I can't seem to find any trace of it on the Unidata web site.
> > > I've been working off of the comments in the source code files,
> > > so far, but there has to be a better way...
> > >
> > > Thanks,
> > >
> > > Travis
>
> ----------------------------------------------------------------------
> Travis Smith                          address@hidden
> National Severe Storms Laboratory     http://www.nssl.noaa.gov/~tsmith
> 1313 Halley Circle                    phone: (405) 366-0474
> Norman, OK 73069                      fax: (405) 366-0472
>