[McIDAS #ANL-325610]: imgdisp.k BAR arg sometimes give errors and WWDISP/FRNTDISP take a longer time to run.

Hi Marty,

re:
> Today has been a rainy day in Logan.  This should be good for
> my peas and onions in my garden:)

The weather here in the front range of Colorado has been spectacular
ever since it stopped snowing last Saturday night.  Gotta love
Colorado... one day it snows, the next people are in shorts and
Tshirts :-)


> I have run into some questions again on our system.  An example
> file on our system is: /usr/local/mcidas/climate/genNEXRADN0R.
> 
> I have noticed that the BAR argument to imgdisp.k somtimes gives
> errors and does not draw the bar.  I have tried it from the command
> line as well and have received the same errors; I appears that
> bar.k does not know where the images are even though imgdisp.k does.
> 
> Example:
> mcenv -f 13@600x800 -g 20 -i 48
> imgdisp.k RTNEXRAD/N0R ID=MTX LINELE=230 230 PLACE=C MAG=1 1 EU=BREF SU=X 
> ALL=1 12 SF=YES BAND= X REFRESH='MAP FILE=OUTLUSAM MCOL=4 WID=1 GRA=(GRA);BAR 
> (GRA) SU=X X COL=7 ORIENT=VER'
> 
> Using defaults assigned to RTNEXRAD/N0R from context file IMGDISP.CORE 
> # Note:  I created a IMGDISP.USER file and commented out RTNEXRAD/N0R  
> entries but still get the errors below.
> 
> Beginning Image Data transfer, bytes= 481004
> IMGDISP: loaded frame  1
> MAP FILE=OUTLUSAM MCOL=4 WID=1 GRA=   1 ;BAR    1  SU=X X COL=7 ORIENT=VER
> Beginning Image Data transfer, bytes= 481004
> MAP: Completed frame 1
> EU: Restoring BREF.ET to frame(s)= 1
> EU: Done
> IMGDISP: loaded frame  2
> MAP FILE=OUTLUSAM MCOL=4 WID=1 GRA=   2 ;BAR    2  SU=X X COL=7 ORIENT=VER
> MAP: Completed frame 2
> BAR: There are no images that meet the selection criteria
> BAR: Error retrieving dataset
> BAR failed, rc=1
> Beginning Image Data transfer, bytes= 481004
> EU: Restoring BREF.ET to frame(s)= 2
> EU: Done
> Done
> IMGDISP: loaded frame  3
> MAP FILE=OUTLUSAM MCOL=4 WID=1 GRA=   3 ;BAR    3  SU=X X COL=7 ORIENT=VER
> MAP: Completed frame 3
> Beginning Image Data transfer, bytes= 481004
> EU: Restoring BREF.ET to frame(s)= 3
> EU: Done
> BAR: There are no images that meet the selection criteria
> BAR: Error retrieving dataset
> BAR failed, rc=1
> ...

I understand.  This is a result of a your distribution not having
been updated to the latest addendum, v2008d.  The addenda issued
since the version you are using, v2008a, contained some bug fixes
for a number of things, one of which was exactly what you are
running into with the example above:  There was an issue with
matching the time of the displayed image down to the second or
minute.  In one iteration, a bug was introduced where the time
requested in an ADDE call was down to the second, while the
server was truncating to the minute.  This resulted in a mismatch
in times requested and seemingly available, hence the error
message:

There are no images that meet the selection criteria

The v2008d addendum fixed that bug by causing the server to truncate
both the requested image time and indicated image time to the
minute.

I downloaded the latest McIDAS 2008 addendum to your machine and am
rebuilding the distribution from scratch:

<as 'mcidas' on cldbz1>
cd ~mcidas/mcidas2008/update
ftp ftp.unidata.ucar.edu
  <user>
  <pass>
  cd unix/2008/bugfix
  binary
  get mcupdate.tar.gz
  get mcupdate.list.2008b
  get mcupdate.list.2008c
  get mcupdate.list.2008d
  quit

cd ..
mv tcl tcl.orig
mv tk tk.orig
cd update
./mcupdate

cd ../src
make clobber
make all

NOTE:  I am running into a problem building the modules 'nvprep.for'
and 'kbprep.for' in ~mcidas/mcidas2008/src.  I ran into a similar
thing on our Solaris 10 x86 machine, but was able to solve it by
changing the PATH in scope during the McIDAS build.  A similar
action did _not_ work on your machine, so I SCPed 'nvprep.for'
and 'kbprep.for' from our Solaris x86 10 machine to get things going.
I will write more when I have figured out the correct PATH, etc.
on your system.

> Also, I have noticed that the WWDISP/FRNTDISP commands are a lot slower
> than our other system.  The WWDISP command takes about 30 seconds each
> time it is run.  I was wondering if these commands were pulling their
> information from the web somewhere or getting it local from our LDM.

Both commands access data from the ADDE RTWXTEXT dataset.  Where you
are getting this data will depend on your client routing setup.  You
check this with:

<as 'mcidas'>
cd $MCDATA
dataloc.k LIST RTWXTEXT

Group Name                    Server IP Address
--------------------         ----------------------------------------
RTWXTEXT                     <LOCAL-DATA>

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done

This listing says that you are getting the data from the local ADDE service,
not a remote one.  Why it is so slow is unknown to me right off, but I will
poke around.

By the way, I notice that the load average on your machine is pretty high:

-bash-3.00$ uptime
 12:04pm  up 16 day(s), 23:46,  3 users,  load average: 11.19, 9.99, 9.06

I wanted to run 'top' to get an idea of what is chewing up the CPU cycles
on the machine, but 'top' is not installed (typically found in /opt/csw/bin).
Can you install 'top' so we can use its diagnostic capabilities to investigate
why the load average is so high?  Thanks in advance...

> Thanks in advance for your help.

No worries.

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: ANL-325610
Department: Support McIDAS
Priority: Normal
Status: Closed