20010723: Problem running GEMPAK5.6

James,

does your LDM account automatically source the Gemenviron file?

If you already have $GEMEXE in you path, when you source Gemenviron,
it will tag the 5.6 path on at the end of you path so when you
type sfl604, you would be executing the 5.4 version with the 5.6 value of 
$GEMNTS.


Try typing "which sfl604". It should  be your /home/ldm/5.6/bin/sol/sfl604.
If it is still pointing to your 5.4 distribution, try setting PATH before
sourcing Gemenviron, like:

setenv PATH /usr/bin:/bin:.:/usr/local/bin:/usr/ucb
source Gemenviron

This will make sure that the 5.4 executables aren't in your
path when the 5.6 $GEMEXE is appended. The reason Gemenviron sticks the
$GEMEXE at the end of your path is so if you type "ps", you get the /usr/bin/ps
and not the Gempak postscript driver.

There was a change in the $GEMPDF and $GEMPARM file formats between 5.4 and 5.6,
so the wrong executable will not be able to correctly process the help/settings.

Let me know what you find.

Steve Chiswell
Unidata User Support


>From: James Murakami <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200107232300.f6NN0S112186

>Hello Steve,
>
>When I told you that invoking a program like SFL604
>produced nothing else, that wasn't completely an
>accurate description.
>
>When I ran SFL604 using the ldm account, this
>is what I did--
>
>       /home/ldm/5.6> source Gemenviron
>       /home/ldm/5.6> sfl604
>       [IP -2]  The global parameter file GEMGLB.NTS cannot be opened.
>       Parameters requested:.
>       GEMPAK-SFL604>
>
>
>
>The content of the gemglb.nts was--
>
>       $RESPOND
>       SFFILE
>       OUTPUT
>       AREA
>       DATTIM
>       SKPMIS
>       IDNTYP
>       SFPARM
>
>Even if I tried typing in each variable, it responded with
>a "unrecognized parameter" statement.
>
>
>Now, when I ran it using my own account--
>
>       source /unidata/ldm/5.6/Gemenviron
>       Parameters requested:.
>       GEMPAK-SFL604>
>
>The difference was that I actually could run the program.
>My pre-existing gemglb.nts served as the guide. Nonetheless,
>none of the parameter lines showed up when I commanded "list".
>
>I ran into a similar situation with SFMAP.  Ntl programs
like "ntrans" and "nsat" work fine though.
>
>I did check the various $GEM*** in the Gemenviron file.
>They all seem to point to the proper directories. 
>I had established the new version with a directory "5.6" name.
>The current version accesses files from the directory "5.4"
>(both reside separately at /home/ldm).
>
>So, I'll take any other tips for tracking down the culprit
>to this problem. I'm so close, yet so far.
>
>James
>
>--------------------------------------
>James Murakami
>Staff Meteorologist/Student Affairs
>Department of Atmospheric Sciences
>University of California, Los Angeles
>405 Hilgard Ave.
>Los Angeles, CA  90095-1565
>
>
>   e-mail:  address@hidden
>telephone:  310-825-2418
>      Fax:  310-206-5219
>---------------------------------------
>
>>James,
>>
>>If you are invoking a program name, and don't see anything, then you may have
>>$GEMPRM, $GEMHLP, etc pointing to a wrong location- if you haven't
>>sourced Gemenviron, or still have your old distribution locations
>>in your environment.
>> 
>>Also, make sure you didn't download the new distribution on top of your old
>>source distribution tree. If you do that, and you haven't removed
>>all of the files in the $GEMLIB directory, then you will have old
>>libraries and not compiled the new versions.
>> 
>>Steve Chiswell
>>Unidata User Support
>