Jennifer,<br>I have attached a <i>somewhat</i> simplified version of the script I&#39;m running.  The significant part of it is the loop (while a &lt;= ensemble_size) ...<br>I put &#39;!date&#39; statements in to see how long each iteration of the loop takes.  Here is representative output from that loop:<br>
<br>Mon Jan 21 13:55:23 CST 2013<br>Mon Jan 21 13:55:43 CST 2013                <br>Mon Jan 21 13:56:08 CST 2013<br>Mon Jan 21 13:56:33 CST 2013                <br>Mon Jan 21 13:57:01 CST 2013<br>Mon Jan 21 13:57:34 CST 2013                 <br>
Mon Jan 21 13:58:05 CST 2013<br>Mon Jan 21 13:58:38 CST 2013                            <br>Mon Jan 21 13:59:13 CST 2013<br>Mon Jan 21 13:59:48 CST 2013                 <br>Mon Jan 21 14:00:29 CST 2013<br>Mon Jan 21 14:01:12 CST 2013                 <br>
Mon Jan 21 14:01:56 CST 2013<br>Mon Jan 21 14:02:39 CST 2013                 <br>Mon Jan 21 14:03:26 CST 2013<br>Mon Jan 21 14:04:14 CST 2013                <br>Mon Jan 21 14:05:07 CST 2013<br>Mon Jan 21 14:06:02 CST 2013                 <br>
Mon Jan 21 14:07:01 CST 2013<br>Mon Jan 21 14:08:03 CST 2013<br><br>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?<br>
<br>Jeff<br><br><div class="gmail_quote">On Thu, Jan 17, 2013 at 4:50 PM, Jennifer Adams <span dir="ltr">&lt;<a href="mailto:jma@cola.iges.org" target="_blank">jma@cola.iges.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi, Jeff --<div>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 &#39;flush&#39; command if you are sure you won&#39;t need any of the previously-read grids again. It is part of the &#39;reinit&#39; command, and I just put it in there as a separate command in case it became necessary, but I don&#39;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. </div>
<div>--Jennifer</div><div><br></div><div><br></div><div><br><div><div><div class="h5"><div>On Jan 17, 2013, at 5:16 PM, Jeff Duda wrote:</div><br></div></div><blockquote type="cite"><div><div class="h5">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&#39;m doing.<br>
<br>
I&#39;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&#39;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&#39;m just feeling around here to see if the flush command may enable my scripts to run faster.<br>

<br>Jeff Duda<br clear="all"><br>-- <br>Jeff Duda<br>Graduate research assistant<br>University of Oklahoma School of Meteorology<br>Center for Analysis and Prediction of Storms<br></div></div>
_______________________________________________<br>gradsusr mailing list<br><a href="mailto:gradsusr@gradsusr.org" target="_blank">gradsusr@gradsusr.org</a><br><a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
</blockquote></div><br><div>
<span style="border-spacing:0px 0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:12px;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="border-spacing:0px 0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:12px;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="border-spacing:0px 0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:12px;white-space:normal;font-family:Helvetica;word-spacing:0px"><div>
--</div><div>Jennifer M. Adams</div><div>IGES/COLA</div><div>4041 Powder Mill Road, Suite 302</div><div>Calverton, MD 20705</div><div><a href="mailto:jma@cola.iges.org" target="_blank">jma@cola.iges.org</a></div><div><br>
</div><br></span></span></span>
</div>
<br></div></div><br>_______________________________________________<br>
gradsusr mailing list<br>
<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Jeff Duda<br>Graduate research assistant<br>University of Oklahoma School of Meteorology<br>Center for Analysis and Prediction of Storms<br>