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

[Datastream #IZJ-689237]: Additional Datafeeds



Hi Jeff,

I may have some good news for you!

We continued testing on another user's 64-bit, RedHat Enterprise 5 Linux 
machine (where
we had 'root' login) and determined that GEMPAK 5.11.4 versions of 'dcacft' and 
'dcmsfc'
run with no problems (i.e., do not create huge output files and do not write 
the persistent
'Cannot read file ....' and/or 'Cannot write to file ....' entries in the 
gempak log files).
We ran Garp remotely on the files created by these decoders and were able to 
generate correct
plots.

Just so you know, the Unidata 5.11.1 version of dcgrib2 appears to be working 
without
problems on the other user's machine.  In fact, the only decoders that appeared 
to be having
problems were 'dcacft' and 'dcmsfc'.

To setup things up for you to be able to test the 5.11.4 decoders, I have done 
the following
on whistler:

<as 'ldm'>
cd ~ldm
mkdir decoders5.11.4
-- copy all of the GEMPAK 5.11.4 decoders to the ~ldm/decoders5.11.4 directory
-- copy the file libgfortran3.0.0 to the ~ldm/decoders5.11.4 directory

cd ~ldm/decoders
mkdir backup
mv *.5.11.1 backup
mv dcgrib2.allright backup


What you need to do to use one or more of the 5.11.4 docoders
** if you feel that you need/want to** is:

<as 'root'>
cd /usr/lib64
cp ~gempak/decoders5.11.4/libgfortran3.0.0 .
ln -s libgfortran3.0.0 libgfortran.so.3

<as 'ldm'>
ldmadmin stop
cd ~ldm/decoders

mv dcacft dcacft.5.11.1
cp ~ldm/decoders5.11.4/dcacft .

mv dcmsfc dcmsfc.5.11.1
cp ~ldm/decoders5.11.4/dcmsfc .

etc.

cd ~ldm/data/gempak/logs
rm *.log.*                   (e.g., *.log.1, *.log.2)
~ldm/util/dcrotatelog.csh

cd ~ldm/data/gempak
-- remove any abnormally large files from any of the sub directories

cd ~ldm
ldmadmin start


Also, we ran Garp from whistler with display back to the UPC.  Since the remote
display was a bit slow, we did not have a chance to check a lot of options that
are available. The ones we did try, however, seemed to work OK.

Question:

- if you are still seeing "data holes", can you give us a list of what things 
you
  were trying to plot when you experienced the "holes".

  This will help us compare your results with results here at the UPC.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: IZJ-689237
Department: Support IDD
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.