[gradsusr] flushing

[Jeff Duda]

Jennifer,
I have attached a *somewhat* simplified version of the script I'm running.
The significant part of it is the loop (while a <= ensemble_size) ...
I put '!date' statements in to see how long each iteration of the loop
takes.  Here is representative output from that loop:

Mon Jan 21 13:55:23 CST 2013
Mon Jan 21 13:55:43 CST 2013
Mon Jan 21 13:56:08 CST 2013
Mon Jan 21 13:56:33 CST 2013
Mon Jan 21 13:57:01 CST 2013
Mon Jan 21 13:57:34 CST 2013
Mon Jan 21 13:58:05 CST 2013
Mon Jan 21 13:58:38 CST 2013
Mon Jan 21 13:59:13 CST 2013
Mon Jan 21 13:59:48 CST 2013
Mon Jan 21 14:00:29 CST 2013
Mon Jan 21 14:01:12 CST 2013
Mon Jan 21 14:01:56 CST 2013
Mon Jan 21 14:02:39 CST 2013
Mon Jan 21 14:03:26 CST 2013
Mon Jan 21 14:04:14 CST 2013
Mon Jan 21 14:05:07 CST 2013
Mon Jan 21 14:06:02 CST 2013
Mon Jan 21 14:07:01 CST 2013
Mon Jan 21 14:08:03 CST 2013

Note that the first few iterations take 20-25 seconds, but that increase to
about 60 seconds by the last few iterations of the loop.  What I want to
know is 1) why is it taking longer despite the same code running, and 2)
can I reduce that time?

Jeff

On Thu, Jan 17, 2013 at 4:50 PM, Jennifer Adams <jma at cola.iges.org> wrote:

> Hi, Jeff --
> GRIB2 records are cached in case you want to reread data from the same
> grid more than once -- having grib records in the cache saves you the time
> of having to re-do the I/O and the uncompression. However, the cache can
> get big, and if you are pushing the memory limits of the your machine, you
> can clear the cache with the 'flush' command if you are sure you won't need
> any of the previously-read grids again. It is part of the 'reinit' command,
> and I just put it in there as a separate command in case it became
> necessary, but I don't think it will fix your slow-down problem. If you can
> provide a script that is as simple as possible but still illustrates the
> slow down, I will take a look.
> --Jennifer
>
>
>
> On Jan 17, 2013, at 5:16 PM, Jeff Duda wrote:
>
> What is the purpose of the command flush?  I see from the documentation
> that it clears the GRIB2 cache.  I think I understand what that basically
> means, but I wonder if it has implications in something I'm doing.
>
> I'm running a series of complicated Grads scripts that read GRIB2 data and
> make a lot of plots.  For some of my plots I am using the set defval
> command.  One thing I've noticed while using this command is that the more
> times I run it in a loop of a Grads script, the longer it seems to take to
> run with each iteration.  I know that sounds non-specific, so I can provide
> script code if anyone wants it, but I'm just feeling around here to see if
> the flush command may enable my scripts to run faster.
>
> Jeff Duda
>
> --
> Jeff Duda
> Graduate research assistant
> University of Oklahoma School of Meteorology
> Center for Analysis and Prediction of Storms
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jma at cola.iges.org
>
>
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>


-- 
Jeff Duda
Graduate research assistant
University of Oklahoma School of Meteorology
Center for Analysis and Prediction of Storms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20130121/8673fd04/attachment-0003.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ensemble_shear_graphics.gs
Type: application/octet-stream
Size: 6800 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20130121/8673fd04/attachment-0003.obj