20000517: notifyme and ldm, MCGUI configuration

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 200005172010.e4HKAp409087 LDM notifyme McIDAS-X MCGUI configuration

Alan,

>A couple more questions re: notifyme
>
>When I run this command the first time on a given day, it performs
>as expected.  I get a long scrolling printout (for DDPLUS anyway),
>and at some point it starts to pause;  at this point it has caught up
>and is showing the data as it is recieved, correct?

Correct.

>So, I have seen enough, and I stop it with Ctrl C.  Ok

OK.

>A few minutes later, I want to look again (short memory) so I type the
>same command again; the message shows it starts OK but there is no 
>output.  Why ?

Without seeing the command typed, I can't tell you.  I would suspect
that the first invocation included the '-o' flag specifying how far
to go back from the present time, and the second invocation did not
include the '-o', but I may be wrong.

>Also, in using the output to judge the delay of data reaching us, it 
>seems to me that of the output list from notifyme that only the last 
>data, where the command has caught up and is telling me of data just
>as it is received, that I can compare the 2 time stamps.

This is how I understand things.

>For the 
>data at the top the output, the first timestamp is stil the current time, 
>and the second is when it was injected,

Correct.

>but if it has been sitting 
>in my file for an hour, wouldn't I expect to see a 1 hour (or longer)
>difference, since I have asked it to go back 1 hr?  

No.  The first time is always the local clock time.  'notifyme' is
using the LDM 'ulog' logging interface which always spits back the
current time as the first time field.

>Can you comment about the comparison of the time stamps for the data
>at the top of notifyme's output, vs the output when it is looking at 
>data just as it comes in?

The comparison tells us nothing about the product latency when looking
back in time via the '-o' flat.  When 'notifyme' has caught up, however,
the current time is a good comparator for the product injection time.

>Just how does the -o (offset) argument 
>determine the way this thing performs?

It simply tells the upstream LDM to look back 'offset' seconds from the
current time in the queue.

>Sorry if I am dense about this, but hey, I am getting old.

Me too :-(

>As long as I have your attention, another question re: MCIDASX
>
>I note that when I use MCGUI to plot an image or an image loop, they
>are put into the frames (1-10) as listed under the configuration button, 
>Modify MCGUI ... .

Right.

>Looking at this configuration menu, I see that upper
>air plots and contours are supposed to go in frame 13 ?

Right again.

>but I am assuming 
>the no. 13 refers to the frame no;

Yes, exactly.

>I also note the term string table on
>this config. screen, so maybe the 13 does not mean Frame.

The values for where various things are plotted are kept in McIDAS strings
which, in turn, are stored in the McIDAS string table.  The reason they
are stored in the string table is so that the settings will be available
the next time you start the MCGUI/Fkey.

-- aside --

All of the strings used by the MCGUI and Fkey menu begin with the '?'
(question mark) character.  Strings that begin with a '?' in McIDAS are
global strings.  The good thing about a global string is that they are
not deleted by a 'TD ALL'.

>Then why do the image loops plot into 1-10, just as listed?

Because, the entry is the definition of the beginning (Begfrm) and ending
(Endfrm) frames for the loop.  I put all of the image loops into frames
1-10 and other plots/contours in frames 11-16 as a convenience.  The
Modify GUI Parameters action is the vehicle by which you can change
these settings.

>When I do an upper air plot or contour, it does not go in frame 13, but 
>goes into whatever frame is current at the time.

This is a bug which I do not see on my system.  The determining factor
for where an upper air plot is supposed to go is the value of the string
?UFRM.  The value listed in the Modify GUI Parameters popup should be
the value stored in the string table.  To verify this, you can run the
following from the McIDAS command line:

TL ?UFRM

If this is not 13 and the value listed for ?UFRM in the Modify GUI Parameters
popup is 13, I need to know since it is some sort of weird bug.

>I think I may be 
>mis-interpreting the Config.  Gui table, but I 'll bet you can tell
>me what is going on.

You are not misinterpreting the configuration table.  The intent was to
give an interface that would allow the user to customize their displays.

By the way, I am always looking for suggestions on what users would like
to see in a GUI, so please pass along any/all comments.

>Not sure I can tell anymore jokes but here's one.

Why not?

>A penguin walks into a bar and asks the barman, "Say has my 
>father been in here"   Barman replies  " I 'm not sure; what 
>does he look like?

Yea, what _does_ he look like?

Tom