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.
Stonie, I had calls to GD_CLOS in gdradr.f that would close the grid file each after each grid which I commented out when the new grid library routines were added. I would suggest adding them back. The GD_WPGD call is supposed to write the grid, and then the last step is the GD_ADDT call which adds the grid to the sorted list, so that should still work. I believe the problem is that even though the write buffers are flushed in the DM_ routines, the operating system or disk IO is still caching the write to disk unless the file is closed (so calling GD_CLOS probably forces the disk output). I think my gdradr.f code needs to be cleaned up. I did the quick porting to new routines, but still need to employ the new features. Steve Chiswell Unidata User Support On Fri, 2006-04-07 at 12:02, Stonie Cooper wrote: > Steve, > > I hope all is going well for you; I was just following up on a > discussion we had a while back on the grid creation of gdradr, and > how with the new gd lib, that the time stamp of a new grid is getting > written before the gridding is complete. This is a problem in that > the slot for a new grid is showing the grid available to programs > like nmap2 . . . before the grid is actually complete. This leads to > the last grid in a loop set not getting loaded - i.e. blank. If you > wait some amount of time and hit reload, the data then appears. > > If a guy was to try to remedy - where would suggest I start looking > in the source? > > Stonie