20030415: McIDAS 7.8 mcgui

>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200304151722.h3FHMs7U002298 McIDAS-X 7.8 MCGUI fronts

Hi Bill,

>I came across something that does not work as expected in McIDAS 7.8's
>mcgui interface. Even though we are a version behind, I thought you
>would want to know in case the same problem exists in the current
>version.

OK, sounds good.

>And if it isn't too hard to fix, I could patch our old version
>with a little shove in the right direction.

I will try.

>The problem involves plotting fronts through mcgui. From the Display
>menu, Observations --> Fronts, brings up the Fronts dialog box. The
>cursor changes to and remains a watch -- active. A process is hanging,
>and never returning.

What is going on at this point is that the MCGUI fires off a process that
asks the server for RTWXTEXT data to send back a list of available
front times.  This is a slow process at best, so it may appear that
a process is hanging when it is not, or it may be that the server your
McIDAS session is point to for the RTWXTEXT data is slow or not
processing the request correctly.  To check this out, change your pointing
to a different server and try the front plotting again:

DATALOC ADD RTWXTEXT papagayo.unl.edu

for instance.

>Back to the prompt, the top command shows the
>culprit is wxtlist.k . If I kill that process, then I can close the
>Fronts dialog box.

That is, indeed, the program that is requesting a list of front times
from the server for RTWXTEXT data.

>I tried to find the error and found the following.
>
>  I did a which mcgui, and found mcgui.k in /usr/local/mcidas/bin .

Right.

>  I did a less mcgui.k and serarched for Fronts. That found the menu
>  button that invokes the command frontPlot. That proceedure seems to be
>  in the file upcguiprocs.tcl, which is not executable. I guess that could
>  be okay.?

Yes, upcguiprocs.tcl contains the Tcl/Tk procedures used in the MCGUI.
The procedures are read in by Tcl/Tk when the main MCGUI process, mcgui.k
tries to read a procedure that is not contained in mcgui.k.  This is all
the way it should be.

>  I did a less upcguiprocs.tcl and searched for frontPlot. Found the
>  proceedure, I think. Down a dozen lines is:
>
># Generate list of valid times
>    set frontTimes [getPlotTimes RTWXTEXT/FRNTDISP TEXT frontTime frontDay]

Right again.

>  RTWXTEXT/FRNTDISP looks like an adde dataset; and we do not have a FRNTDISP
>  descrptor in group RTWXTEXT.

You are correct.  What is done in getPlotTimes is take the dataset
descriptor RTWXTEXT/FRNTDISP and rip it apart into its components:
group -> RTWXTEXT; descriptor -> FRNTDISP.  A switch statement then
uses the descriptor, FRNTDISP, to set two variables: tinc and toff
which are used to generate a list of times for fronts (0, 6, 12, 18).
This call should return almost instantly since the only thing being done
is the creation of a list.

After the widget is created, the procedure that is run that is taking
the time is:

# Generate a list of valid days

    runBusy busy "Generating a list of days with front data"
    set daylist [addeDateList TEXT FRONT_ANAL]
    foreach day $daylist {
        lappend frontDays "$day - [julToString $day]"
    }

The 'set daylist' line runs the procedure addeDateList using the next
two positional parameters as input.  addeDateList uses the TEXT parameter
to set the program to run, WXTLIST, and that program's options.
WXTLIST (wxtlist.k) is then run to go out to the server for RTWXTEXT
data and ask for a list of available frontal dates/times that the server
has.  The command that ends up being run is:

WXTLIST FRONT_ANAL FORM=HEADER NUM=60

It is this command that is taking a long time (or possibly hanging), and
the reason is most likely that the server being interrogated is slow
or not working correctly.  Again, try pointing at a different server
and see if things work.  You will have to be patient, but you should
not have to wait for over a minute or so.

>  I tried,  FRNTDISP OLAY 9   and it works fine.

OK, so the server _does_ have the data, it is just slow in returning
a list of all frontal bulletins that it has.

>So, I thought I would stop here and ask you to comment. Is this easy to
>patch?

I don't think a patch is required at all.  I will cross compare the
frontPlot procedure in v2002x with that in 7.8 to make sure that there
is nothing different, but I don't think there is since my History
list at the top of the frontPlot procedure does not indicate any
change from v7.8 to v2002.

Tom