[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990326: Gempak bug? - Linux distribution

Bob & Ken,

The problem you are having is that both the machine that created
the file and the machine reading the file (linux aka ultrix)
are the same little endian byte order, but not the same MTMACH.

The problem in dmrflt is that kieeet ( iflno ) and mieeet are both false.

When both machines are big endian,
C
C*          Next, do nothing for IEEE floating point nos.
C
          ELSE IF  ( kieeet ( iflno ) .and. mieeet )  THEN

then no conversion is necessary. Since Alpha and Ultrix/linux
are both little endian, no conversion is necessary, but (F and F) is
false- so the above statement will not work for little endian. 
You should add the following case before the fall through -33 event:

          ELSE IF ( kvmst ( iflno ) .and. mvmst ) THEN
C
C*        Same little endian byte order
C
          ELSE
            iret = -33
            RETURN
        END IF
...etc


Both kvmst(iflno) and mvmst will be true for little endian file order
and little endian architecture.

The dmflip routine I added is called generically by the integer routines,
so there is no problem there in gd/gdgidn.f and gd/gdrdat.f.

To rebuild the dmrflt.o linux routine, remove the old object file from
the archive, then remake:
ar dv $GEMLIB/gemlib.a dmrflt.o
cd $GEMPAKHOME/src/gemlib/dm
make all
make clean

You will have to relink all programs that use gemlib.a and use dmrflt.

Steve Chiswell
Unidata User Support


On Fri, 26 Mar 1999, Robert Rozumalski wrote:

> 
> 
> Ken,  I spoke with Ken Johnson about an hour ago regarding this problem.
> The GEMPAK distribution was ported to Linux by Steve Chiswell at Unidata
> so I'll have to pass this along to him.  If the solution is as simple as
> Karl Suggests, then it shouldn't be a problem.  Hopefully we can have a fix
> by the end of next week.  
>  
> 
> Bob
> 
> 
> > 
> > Bob,
> > 
> > I think you may be the right person for this with your new job title. 
> > Congratulations, by the way!  We've encountered a problem which seems
> > to be a gempak bug of some kind.  When we generate gempak grid files
> > on a DEC Alpha and send them to a Linux system, gempak on the Linux 
> > system won't read them ("Data cannot be translated").  Here is
> > a note from Karl Pfeiffer about what he did to get around it:
> > 
> > Hello.  I am Karl Pfeiffer, a student working for Prof Yuh-Lang Lin.  I
> > have installed GEMPAK 5.4pl8 on our Linux machines and routinely exchange
> > data between the Linux boxes and our DEC Alphas.  To do this, however, I
> > had to modify 
> > 
> >   $NAWIPS/gempak5.4/source/gemlib/dm/dmrflt.f
> > 
> > Lines 137-138 are the fall-through lines that set [DM -33]
> > for a 'Data cannot be translated' error return.  I believe this message is
> > bogus and have commented these lines out.  In effect, if we fall
> > through to this point in the code, nothing happens.  There are probably
> > cleaner solutions, but I have not approached UNIDATA about this.
> > 
> > Since this is part of gemlib, I did a 'make clean' at the head
> > of the source tree, then re-made the GEMPAK installation.
> > 
> > Good luck,
> > 
> > Karl
> > 
> > I talked to Ken Johnson at Eastern Region about it, and he thought
> > it probably should be resolved in a gempak bug fix and new version for
> > the NWS offices if necessary, or something along those lines.  What
> > do you think?
> > 
> > Ken
> > 
>