This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Dave, In order to test Steve's comment about the reason for the LDM not being able to run GEMPAK decoders was due to LD_LIBRARY_PATH not being passed to the environment in which the decoders are run (the environment in which 'pqact' runs), I did the following on twister: <as 'root'> cd /lib64 ln -s /usr/local/miniconda/lib/libpython2.7.so.1.0 . ln -s libpython2.7.so.1.0 libpython2.7.so <as 'ldm'> -- comment out the setting of LD_LIBRARY_PATH in ~ldm/.login unsetenv LD_LIBRARY_PATH ldmadmin restart Since making the above changes, all LDM-initiated GEMPAK decoding appear to be working as they should. One example: [ldm@twister ~]$ ls -alt /data/ldm/gempak/surface total 5000 -rw-rw-r-- 1 ldm programs 5101568 Sep 3 12:39 20160903_sao.gem drwxrwxr-x 2 ldm programs 4096 Sep 3 12:30 . -rw-r--r-- 1 ldm programs 0 Sep 1 19:50 .scour* drwxrwxr-x 29 ldm programs 4096 Apr 10 2015 .. NB: Steve and I talked to Michael James about the Python lib dependency in the GEMPAK decoders provided in the v7.x rpms, and, after review, he said that there should not be any dependency on the Python shared library for the decoders. I expect, therefore, that he will be recreating the latest GEMPAK rpm after getting rid of that dependency (but I have no ETA for when this may be available). Final comment: This was an "interesting" problem :-) Steve Emmerson wrote: > Found the problem (I was off-base). > > The GEMPAK decoders require a Python shared library: > > [ldm@twister etc]$ ldd /home/gempak/GEMPAK7/os/linux64/bin/dcgrib2 > ... > libpython2.7.so.1.0 => /usr/local/miniconda/lib/libpython2.7.so.1.0 > (0x00007f92f1435000) > ... > > and won't work it it can't be found: > > [ldm@twister etc]$ LD_LIBRARY_PATH= ldd > /home/gempak/GEMPAK7/os/linux64/bin/dcgrib2 > ... > libpython2.7.so.1.0 => not found > ... > > and the pqact(1) process doesn't have LD_LIBRARY_PATH set: > > [ldm@twister etc]$ ps -p 13761 -ww e | fgrep LD_LIBRARY_PATH > [ldm@twister etc]$ > > Probably because ldmadmin(1) is a Perl script and the perl(1) utility deletes > that > environment variable. > > A solution might be to use yum(8) to install the native Python library. It > would > likely be installed in /usr/lib64 and, consequently, found by the dynamic > loader. 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: FPM-496740 Department: Support LDM 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.