This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: "Jennie L. Moody" <address@hidden> >Organization: UVa >Keywords: 199907281535.JAA02200 McIDAS GRIB DMGRID Jennie, >Tom, hope you got some relaxing in (maybe you are still off >relaxing) Well, I did take several half days off after the workshop ended. I am diving back into some fun stuff after I plow through some email that has been building up. re: GRIB decoding not working as per my previous assumption >Well, not the way you said they should work. For starters, the >option to use POINTER= on the DMGRID command from within McIDAS >didn't seem to work in resetting the pointer in GRIBDEC.PRO. The POINTER= keyword on DMGRID doesn't change the value in GRIBDEC.PRO; it supercedes the value that DMGRID reads from GRIBDEC.PRO. The sequence is that DMGRID reads GRIBDEC.PRO to get a value that is stored and puts the value in a variable called 'reset'. It then checks to see if this value is overridden on the command line by the POINTER= keyword; if it is, the value specified by POINTER= is used. >But >when I remembered I was running this on aeolus which is still using >code from McIDAS7.1, I decided to look at the source for the decoder >dmgrid and I found that this was a change in the newer distribution, >so, I guess we shouldn't have expected it to work (right?). There are several changes between the 7.1 and 7.5 versions of dmgrid.pgm, but the use of POINTER= has stayed the same. I think that the misconception was that specifying POINTER= would actually change the value in GRIBDEC.PRO; it doesn't. >But, I still thought I would be able to change the value of the pointer >in GRIBDEC.PRO to read the "top" of a new spool file, so I tried to >use the LWU POKE command which you recommended, but this gives an error: > >LWU POKE GRIBDEC.PRO 4096 0 >LWU: Word number specified is past end of file. >LWU: Maximum word number for LW file GRIBDEC.PRO is: This should have worked since the syntax is correct. >I was able to list the value, but couldn't change it: > >LWU LIST GRIBDEC.PRO > 0. 2222337 -2139062144 HEX: 0021E901 80808080 ASCII: ! > 2.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 4.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 6.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 8.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 10.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 12.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 14.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 16.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 18.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 20.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 22.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 24.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 26.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 28.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 30.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 32.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 34.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 36.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > 38.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII: > --END OF LISTING > >I don't get it. Was the file writable? >However, if we play around with just copying the >(er, catting through xcd_run is what I mean) the same file over and >over again until the spool catches up with the pointer, then we >can keep it working....but its a pretty kludgie (sp?) way of >doing things. This doesn't make any sense to me. I can manipulate any file that 'mcidas' owns from a McIDAS-X account running as the user 'mcidas' using LWU POKE with no errors. I suspect something is amiss premission wise, or in a REDIRECTion or MCPATH that is being used to locate GRIBDEC.PRO. >Since we are continuing to access archived files >for a number of different reasons, if you have any more solutions >for changing the pointer, I would be happy to listen to them. Let's find out why things that should be working are not before trying to come up with different techniques. >Is it safe (or stupid) to just copy the new dmgrid source code over >and compile it on aeolus? I don't know if this would work or not. If you really want to try it out, then make a backup copy of the 7.1 version of dmgrid.pgm before you copy over the new one. >Maybe I should start working on a way to decode grib files on windfall >in some way that will not interrupt the real-time data we are ingesting >routinely?? How about you giving me the login to the exact environment in which you are attempting to do the decoding. That way I can go through the steps that I think should work and see what fails. Once things are cleaned up, then we could probably "can" a procedure that is more "pushbutton". >Anyway, its working, but.... But sounds ugly! Later... Tom