[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
19991023: Stand-alone Grib Decoder (cont.)
- Subject: 19991023: Stand-alone Grib Decoder (cont.)
- Date: Sun, 24 Oct 1999 18:39:21 -0600
>From: "Jennie L. Moody" <address@hidden>
>Organization: UVa
>Keywords: 199910221947.NAA19009 standalone grib decoder
Jennie,
I am including the text of the three messages from you in this reply so
that the information gets put into the inquiry tracking system.
It turns out that the problem you were running into was very simple,
at least it seems to be. I logged onto your machine as mccode and
reviewed the information in README.TXT and the mods you made in
mcgribdec/Makefile. Your mods looked completely correct, so I made
no changes. I did, however, change search order in 'mccode's PATH
so that ~mccode/mcidas/bin was first. I don't think that this was
a big deal, but I felt that it would be better to put the directory in
which "locally developed code" (i.e. not part of the McIDAS distribution)
before that in the ~mcidas/bin directory. Check the slight modification
in ~mccode/.profile for exactly what I did (not much).
The next thing I did was to verify that the executable gribdec.k was
viable:
cd mcidas/bin
ldd gribdec.k
libm.so.1 => /opt/SUNWspro/lib/libm.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libF77.so.3 => /opt/SUNWspro/lib/libF77.so.3
libsunmath.so.1 => /opt/SUNWspro/lib/libsunmath.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
Looking good.
Next, I:
cd ~/mcidas/data
ls
./ gbtbpds001.2v3
../ gbtbpds001.4v1
ALLOC.WWW gbtbpds001.av1
gbtbpds001.0v1 gbtbpds001.bv1
gbtbpds001.2v1 gbtbpds001.2v2
Then a quick test of running gribdec.k was next:
cd ~
gribdec.k us008_gf089_99021412_YxQAx 5000 'test'
GRIB messages found:
gribdec.k: done
I figure that this is exactly what you were seeing. Here is the deal:
gribdec.k is a McIDAS program. It will use REDIRECTions or MCPATH to
find data files. So, the file us008_gf089_99021412_YxQAx is not found
since it is not in the MCPATH that is in scope:
echo $MCPATH
/q5/usr/mccode/mcidas/data:/home/mcidas/data:/home/mcidas/help
and there are no REDIRECTion since there is no LWPATH.NAM file. Ok, this
makes things easy. The next test was:
cd mcidas/data
mv ~/us008_gf089_99021412_YxQAx .
gribdec.k us008_gf089_99021412_YxQAx 5000 'test'
GRIB messages found: 154
gribdec.k: done
ls
./ gbtbpds001.2v2
../ gbtbpds001.2v3
ALLOC.WWW gbtbpds001.4v1
GRID5005 gbtbpds001.av1
gbtbpds001.0v1 gbtbpds001.bv1
gbtbpds001.2v1 us008_gf089_99021412_YxQAx
154 GRIB messages were found and decoded into GRID file 5005:
igg.k LIST GRIDF=5005
Grid file: 5005 **test **
# YYDDD HHMMSS NAME LEVEL SRC VT NR NC LLNW ROWINC COLINC
----- ----- ------ ---- ------- ---- -- -- -- -------- ------ ------
1 99045 120000 W 100 MB ETA 0 65 93 -PS-
2 99045 120000 W 150 MB ETA 0 65 93 -PS-
3 99045 120000 W 200 MB ETA 0 65 93 -PS-
4 99045 120000 W 250 MB ETA 0 65 93 -PS-
5 99045 120000 W 300 MB ETA 0 65 93 -PS-
6 99045 120000 W 350 MB ETA 0 65 93 -PS-
7 99045 120000 W 400 MB ETA 0 65 93 -PS-
...
So the entire problem was one of the grib message files not being located
in a MCPATH directory. What to do? I would suggest that you could
setup file REDIRECTions that point to the grib message files something like:
cd ~mccode/mcidas/data
redirect.k ADD gb14\* \"/q5/usr/mccode
Now, there will be an LWPATH.NAM fiule in the ~mccode/mcidas/data directory
that will be used to locate the files gb14*. As a test, I ran:
rm GRID5005
gribdec.k gb1412E 5000 'test 2'
ls
./ gbtbpds001.2v2
../ gbtbpds001.2v3
ALLOC.WWW gbtbpds001.4v1
GRID5005 gbtbpds001.av1
LWPATH.NAM gbtbpds001.bv1
gbtbpds001.0v1 us008_gf089_99021412_YxQAx
gbtbpds001.2v1
igg.k LIST GRIDF=5005
Grid file: 5005 ** **
# YYDDD HHMMSS NAME LEVEL SRC VT NR NC LLNW ROWINC COLINC
----- ----- ------ ---- ------- ---- -- -- -- -------- ------ ------
1 99045 120000 W 100 MB ETA 24 65 93 -PS-
2 99045 120000 W 150 MB ETA 24 65 93 -PS-
3 99045 120000 W 200 MB ETA 24 65 93 -PS-
4 99045 120000 W 250 MB ETA 24 65 93 -PS-
5 99045 120000 W 300 MB ETA 24 65 93 -PS-
6 99045 120000 W 350 MB ETA 24 65 93 -PS-
...
Looks like gribdec.k works nicely. All we have to remember is that it
is a McIDAS program and, therefore, finds files by McIDAS rules: REDIRECT
and MCPATH.
The following is the text from the three emails on this subject.
Responses to questions are included as always.
>Date: Sat, 23 Oct 1999 00:35:56 -0400 (EDT)
>The -vendor parameter seemed to fix things, yes I built mcidas
>with the Sun compilers. So, the build and install of the
>gribdecoder seemed to work okay. However, when I try to
>run the decoder, it says it isn't decoding any grib messages...
>I'll mess around a bit more with it (check a couple other
>grib files), but if I get hung, its it fair to ask Chad
>if he might know whats up?
No, it really isn't fair to ask Chad, but in a pinch I would not
hesitate, but I would let Chad know the situation.
>From address@hidden Sat Oct 23 13:50:10 1999
>Well, I am stumped. I am probably doing something wrong, and thats why
>I cannot get the gribdec.k program to process any grib files. I have
>moved several files into the local directory to try decoding them
>(grib1412, gribYAA, AWIP3D06.tm00, these should all be different
>types..the first is a full days worth (well, actually I mean a full
>model run, of analysis plus forecast, which normally gets broken into
>multiple grid files...when we process using the xcd_run that is). The
>second should be a MRF grib file (though we couldn't decode it on
>aeolus, this is one of the files that you decoded successfully out at
>Unidata, and we decided the problem was my old version of mcidas that
>aeolus was running (7.1 on an old aix machine). The last (AWIP...) is
>a grib file I had pulled off the NCEP page, and again, I was able to
>read it with the old kludge method running on aeolus. None of these
>give me anything with the standalone decoder. I just get a message
>indicating no grib messages were processed.
>I did look at the program, and tried adding some print statements
>(potentially dangerous, I suppose), just trying to see if the program
>was doing anything...but then it wouldn't compile. So, I dropped my
>edited copy and restored and re-built/installed the original
>gribdec.pgm.
>I doubt if you want to look at this, but if you do, the mccode info is ...
>I dumbly thought I needed to make a new user, because it
>said to be sure not to build the program under mcidas or oper or any
>account running McIDAS-XCD (I guess it meant specifically the
>mcidas-xcd software, which only the ldm/mcidas run on my system, but I
>thought it meant any account running McIDAS). I wish I understood this
>better.
>At least the kludge method works over on aeolus, may be time to drop
>back and punt.
>(One last question...any reason to believe that the decoder would only
>work with 7.6 and not 7.4,
No.
>I still have the runtime link pointing at
>7.4 on windfall. Why? Several reasons. But I feel particularly
>tentative about switching things over now, when you wont be around if
>things break(!).
No problem.
>I get so discouraged when I spend time trying to get information to
>work with, rather than working with the information (sigh...feeling
>beaten).
You were 99.9% finished. All that tripped you up was the normal REDIRECT
and MCPATH BS.
>From address@hidden Sun Oct 24 12:41:29 1999
>Well, let me try one more question. I have identified part of the problem,
>though I still don't know how to clean it up! The Makefile environment
>for building gribdec.k includes the following:
>
>MCCOMP = mccomp
>MCROOT = /home/mcidas
>MCLIB = $(MCROOT)/lib
>MCMAIN = $(MCLIB)/main.o
>MCHOME = /q5/usr/mccode/mcidas
>HOME_BIN = $(HOME)/mcidas/bin
>MCHOMEDATA = $(MCHOME)/data
>MCHOMEHELP = $(MCHOME)/help
>INCARGS = -I. -I$(MCROOT)/inc
>LIBARGS = -L. -L$(HOME)/mcidas/xcd/src -L$(MCLIB) \
> -lmcidas -lm
>The LIBARGS is the problem (though I don't get an
>error message) but the following doesn't make any sense (obviously I
>guess):
>mccomp -vendor -o gribdec.k gribdec.o Mcgribdecoder.o Mcmkmcgrid.o
>Mcupackbit.o
> Mcisbitset.o Mcgtpstrg.o Mcibmfloat.o Mcgetmemory.o /home/mcidas/lib/main.o
> -L.
> -L/q5/usr/mccode/mcidas/xcd/src -L/home/mcidas/lib -lmcidas -lm
>f77 -o gribdec.k gribdec.o Mcgribdecoder.o Mcmkmcgrid.o Mcupackbit.o
> Mcisbitset.o Mcgtpstrg.o Mcibmfloat.o Mcgetmemory.o /home/mcidas/lib/main.o
> -L.
> -L/q5/usr/mccode/mcidas/xcd/src -L/home/mcidas/lib -R/usr/dt/lib
> -L/usr/dt/lib
> -R/usr/openwin/lib -L/usr/openwin/lib -R/opt/SUNWspro/lib -L/opt/SUNWspro/lib
> -lmcidas -lm -lgen -lsocket -lnsl -lm
If an executable is created by the make, and an 'ldd' of the executable
doesn't show that there are libraries that couldn't be found, then things
are most likely OK.
>First of all, its totally apparent that it cannot find whatever its
>expecting to locate in the LIBARG of $(HOME)/mcidas/xcd/src (this
>directory doesn't even exist), so, what is it really looking for, the
>xcd src code?? or the xcd libraries?
This comes from the way that SSEC does things and the way I do things.
In SSEC McIDAS, XCD is a separate package that gets built, installed,
configured, and run from a separate account (like Chad's instruction
to create a 'mccode' user). I always thought that this was nuts so
I changed it.
>I could set it to find in
>$(MCLIB)/libxcd.a. There is no /home/mcidas/xcd/src, so I don't have a
>clue what Chad was trying to point to, would he have moved some pieces
>of xcd source code into a local mcidas/xcd/src directory, but forgot to
>mention this part?
The build worked; gribdec.k ran; it just couldn't find the grib file to
decode.
>Here is his original Makefile Environment Variables
>from the contrib gribdec.tar file:
>MCCOMP = mccomp
>MCROOT = /home/chadj/mcidas
>MCLIB = $(MCROOT)/lib
>MCMAIN = $(MCLIB)/main.o
>MCHOME = $(HOME)/mcidas
>HOME_BIN = $(HOME)/mcidas/bin
>MCHOMEDATA = $(MCHOME)/data
>MCHOMEHELP = $(MCHOME)/help
>INCARGS = -I. -I$(MCROOT)/inc
>LIBARGS = -L. -L$(HOME)/mcidas/xcd/src -L$(MCLIB) \
> -lmcidas -lm
>
>CHeaders = xcd.h \
> grib.h
>
>CSrc = Mcgribdecoder.c \
> Mcmkmcgrid.c \
> Mcupackbit.c \
> Mcisbitset.c \
> Mcgtpstrg.c \
> Mcibmfloat.c \
> Mcgetmemory.c
>
>DataFiles = gbtbpds001.0v1 \
> gbtbpds001.2v1 \
> gbtbpds001.2v2 \
> gbtbpds001.2v3 \
> gbtbpds001.4v1 \
> gbtbpds001.av1 \
> gbtbpds001.bv1
>The CSrc files above are all in the same directory as the makefile,
>(included with the tar distribution), so I am wondering what the
>-L$(HOME)/mcidas/xcd/src part of the LIBARGS assignment above is
>actually supposed to be pointing to???
Unfortuantely, I don't have time to fully explain why SSEC does things
their way.
>I looked at the makefile for the building of mcidas, and you use the following
>ARG definitions. I guess this didn't help me
>LIBARGS = -L. -lmcidas
>XCDXLIBARGS = -L. -lxcd -lmcidas -lX11
>My guess is that when I run the compiled gribdec.k binary, it expects
>the xcd libraries to be available, but they aren't.
Nope. The McIDAS and XCD libraries are statically built. All subroutines
that are needed are already linked into the executable.
>I also have a bunch of extraneous things getting set as LIBARGS and INCARGS,
>this is presumably because I copied over *my* PATH as a starting point, and I
>have some of these directories (eg: /usr/openwin/bin:/usr/dt/bin:) in
>my PATH. I thought I could get rid of this if I droped them
>from the PATH of this account, so I changed the PATH (in the .profile),
>logged out and logged back in. Its weird that
>they are still here in these arguments, isn't it?
>Sorry to keep bugging you with this, but if its a *simple* fix to the
>LIBARGS line, then maybe I could get this to work?
It was a simple fix after all.
Tom
>From address@hidden Sun Oct 24 20:30:17 1999
>Thanks so much for the assistance, I might have been 99.9% there, but
>this isn't horse shoes...so the score was still zero for me, mcidas
>always wins.
>Anyway, you probably saw that I had gone ahead and made a change to
>include the xcd-libraries (my last effort to fix things). Guess this
>made no difference anyway.
>I did move some gribs that I needed this afternoon over to aeolus, and
>decoded them there. But I never even got around to working with them
>(its soooo slow on aeolus). So, you have helped me immeasurably.
>Thanks. Now I can finish my work, and Owen can start cranking on some
>grids we need to get analyzed for our AGU/AMS papers.
>Many thanks. And I'm glad it was straight forward, I didn't want to
>bug you since I know your busy getting ready for Australia.
Jennie