19990607: operands in sfparm

Bob, Steve and Dave:

FYI- SFPARM=sstc*1.8+32
Is not a valid expression in GEMPAK as its distributed from Mary.

Gempak only allows 1 expression symbol in the sfparm statement.

I modified the Unidata distribution to loop so that expressions
such as the above would work. This explains why his Linux version works
and the HP-UX version he did not get from Unidata does not work.

I sent the attatched message below to Peggy and Jim, and Mary and Scott
in Nov 1996. 

Steve


From address@hidden Wed Nov 13 08:49:36 1996
Date: Wed, 13 Nov 1996 08:49:35 -0700 (MST)
From: Steve Chiswell <address@hidden>
To: Scott Jacobs <address@hidden>, 
    Mary Desjardins <address@hidden>
cc: Peggy Bruehl <address@hidden>, Jim Cowie <address@hidden>
Subject: Arithmatic operations in SFPARM
Message-ID:
<address@hidden>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
X-Status: 




Mary and/or Scott,

I have a question regarding the use of arithmatic operators
in SFPARM. For instance in SFLIST/SFMAP, one of my users wanted
to use:
SFPARM = tmpc*1.8+32

The above results in TMPC * -9999 being plotted.

After looking at the pcslcd.f code, I find that only one
arithmatic operator is allowed, and it must immediately
follow the parameter. Thus  1.8+32 is considered
the single operand on the right hand side- which is left
as -9999 after the conversion to a real number.

After reading the SFPARM documentation, I interpreted it
as allowing more than a single operator, so long as
all the operators preceeded qualifiers.

I have tried the following change to pcslcd.f:
from:
C
C*              Check for start of new condition.
C
                IF  ( ( ( ip .ne. 0 ) .and. ( cc .ne. ' ' ) .and.
     +                  ( ( ip .gt. 4 ) .or. ( j .eq. 1 ) ) ) .or.
     +                  ( j .eq. lenc ) )  THEN


to:
C
C*              Check for start of new condition.
C
                IF  ( ( ( ip .ne. 0 ) .and. ( cc .ne. ' ' ) .and.
     +                ( ( ip .gt. 4 ) .or. ( j .eq. 1 ) .or.
     +                ( (ip.le.4).and.(j .gt. icond+1) ) ) ) .or.
     +                ( j .eq. lenc ) )  THEN


The above change allows an operator to be interpreted 
as long as it does not directly follow another operator.
This allows for unary operators.

The following work with the above change:

SFPARM = tmpc * 1.8 + 32
SFPARM = tmpc * -1
SFPARM = tmpc * -1E3
SFPARM = tmpc * 1.8 + 32 > 50


The following will not work with the above:
SFPARM = tmpc * 1E-3


this gets interpreted as: tmpc * 1E0 - 3,
though the solution would be to instead use:
SFPARM = tmpc * .001



Since the above work around for multiple operators 
has potential side effects when the operator is used within 
an exponential number expression, and since I wasn't clear on the
intent of the documentation I wanted to let you review the matter.

Elsewise, there is probably a need to avoid multiplying 
the parameter by -9999 when the operand conversion to a real fails.

Steve Chiswell
Unidata User Support
address@hidden
















On Mon, 7 Jun 1999, Bob Rozumalski wrote:

> 
> 
> Steve;  Just for your information.   I don't know if you
> were familiar with this (potential) problem.
> 
> Bob
> 
> 
> ------------- Begin Forwarded Message -------------
> 
> >From address@hidden Fri Jun  4 14:48 MDT 1999
> Received: from localhost (sad@localhost)
>       by comet.ucar.edu (8.9.1b+Sun/hub.cf) with ESMTP id OAA14213;
>       Fri, 4 Jun 1999 14:48:43 -0600 (MDT)
> Date: Fri, 4 Jun 1999 14:48:43 -0600 (MDT)
> From: "Steve A. Drake" <address@hidden>
> To: address@hidden
> cc: Bob Rozumalski <address@hidden>, address@hidden
> Subject: Re: GARP... (fwd)
> In-Reply-To: <address@hidden>
> Message-ID: <address@hidden>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Content-Length: 3311
> Status: RO
> 
> On Fri, 4 Jun 1999, David Himes wrote:
> 
> > 
> > Steve,
> > 
> > Could you comment on this, to S. Zubrick.  Thanks...Dave
> > 
> > According to Steven Zubrick:
> > > Date: 03 Jun 1999 16:51:37 -0400
> > > From: Steven Zubrick <address@hidden>
> > > To: address@hidden, address@hidden, address@hidden
> > > Subject: GARP...
> > > Content-Type: text
> > > Content-Length: 1082
> > > 
> > > 
> > > Dave/Jim/Keith...
> > > 
> > > Dave/Jim:If you are not answering GARP questions...I understand...and 
> > > just 
> reply
> > > saying so...
> > > 
> > > However...a quick question....which actually may be a GEMPAK 
> question...(Keith)
> > > 
> > > In GARP, I am attempting to plot sea surface temperatures from either 
> > > ships 
> or
> > > fixed buoys in degrees F (rather than Celcius). In the Garp_defaults 
> > > file, I
> > > have a line that looks like:
> > > 
> > > boy_parms:
> > > 
> "BRBK:1.4:1.4;TMPF;BLNK;SMSL;PTND;SSTC*1.8+32;WHGT*3.281;BLNK;BLNK;BLNK:BLNK"
> > > 
> > > The parameter in question is the entry that looks like "SSTC*1.8+32".
> > > 
> > > On my linux machines (one running Red-Hat 5.2; the other running an older
> > > Slackware 3.3) ... the plotting model for the buoys or ships correctly 
> > > plots 
> the
> > > SSTC parameter in degrees Fahrenheit (which is what I want).
> > > 
> > > However, on my HP boxes (running HP/UX 10.20), the sea surface 
> > > temperature 
> plots
> > > (using the above line) as a very large negative number.
> > > 
> > > My question...what is going on? Why does the SSTC plot correctly on the 
> linux
> > > PCs...but
> > > incorrectly on the HP boxes?
> > > 
> > > Thanks in advance for any assistance you can on this!
> > > 
> > > Steve Z.
> 
>  Hi Steve. It sure sounds like a byte order problem you are having. It
> is likely that the data was stored in a GEMPAK file on a Linux box
> (PC) and thus is using that (little endian) byte ordering.
> 
>  Bob Rozulmalski is ordering a Linux box, but as of right now we don't
> have one here at COMET. Dave mentioned that Steve Chizwell at Unidata
> would create Linux executables, including GARP for Peggy. So, Steve has
> familiarity with the peculiarities of byte swapping. 
> 
>  It is possible that Steve Chizwell implemented a GEMPAK fix to determine
> the byte order of the raw data and automatically byte swap, if necessary.
> I'm cc'ing Bob, since he should be able to tackle this problem when he
> gets his Linux box. In the mean time, you could check the Unidata help
> pages at http://www.unidata.ucar.edu/. Looking ... I found one that says:
> 
> I have enabled N-AWIPS 5.4 to access case study and other data sets which 
> are generated on machines architectures with different byte ordering.
> In the past, case studies produced at COMET under the HP architecture had 
> elements such as Ntrans meta files, NIDS data sets, and data files which 
> could not be read by OSF/1, Ultrix, and other platforms (eg Linux) which 
> required byte flipping. Moreover, sites which had a mix of these 
> architectures would not be able to generally share their files among 
> machines within their lab. To facilitate case study use, as well as to
> enhance the ability for sites to exchange model data and output files with 
> other Universities and the NWS, byte flipping capabilities have been 
> incoporated in the UPC release. These modifications have been provided
> back to NCEP for their future use.
> 
> 
> So, it sounds like this problem was fixed in N-AWIPS 5.4.
> 
> ------------- End Forwarded Message -------------
> 
>