20060412: gdradr file writing.

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