>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.