Unfortunately I have no control over the hardware/technology. I use a shared machine and am just one of many users.<br><br>Jeff<br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 8:38 PM, Muhammad Yunus Ahmad Mazuki <span dir="ltr"><<a href="mailto:ukm.yunus@gmail.com" target="_blank">ukm.yunus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jennifer and Jeff,<br>
<br>
I'll share some of my experience, I'm not sure whether it will help<br>
you. When you read from many files and writing many files at the same<br>
time, the speed of your hard disk limits the speed of your computer in<br>
running your loops. One of my solution was to copy my file into the<br>
ram literally, in Ubuntu, by copying my binary(nc, grib, idx, ctl and<br>
also gs) files into /dev/shm which is actually the physical ram of the<br>
computer. I also copied the scripts into the folder (copying into the<br>
ram actually), and set to produce the output inside the ram folder as<br>
well. This has the effect of reducing my loops from 12 minutes to a<br>
mere 4 minutes.<br>
<br>
On that note, it seems that the GrADS version I'm using, 2.0.a9, does<br>
not support multiple core processer usage, it only use one. When I<br>
used 4 GrADS instances but reading and writing from a single HDD, it<br>
just total up to 12x4=48 minutes. But when I used 4 GrADS instances<br>
and reading and writing inside RAM, its parallel processing, resulting<br>
in total of 4 minutes only, instead of 48 minutes. So, even if you<br>
used really good HPC, but you use only a single old spinning HDD, your<br>
processing speed will be limited to your HDD speed. You may want to<br>
invest in a RAID array setup, as it will at least increase read/write<br>
speed by two times, and this will reduce the time it taken to complete<br>
your loops.<br>
<br>
As for your statement in the loops taking longer time in the end, I<br>
believe its just the bottleneck problem, where your data to be written<br>
has piled up so much, that your HDD is running at full speed. So<br>
previously, even though I used quad processor computer, my speed in<br>
processing is limited to my HDD speed. When I look at my processor<br>
usage, it goes down an up. Now, when I read/write to RAM directly, the<br>
processor stays at 100% usage until the end of the process, all 4<br>
processors in fact from running 4 instances of GrADS.<br>
<br>
Is there a future plan for GrADS to support multicore usage?<br>
<span class="HOEnZb"><font color="#888888"><br>
Yunus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Jan 22, 2013 at 4:14 AM, Jeff Duda <<a href="mailto:jeffduda319@gmail.com">jeffduda319@gmail.com</a>> wrote:<br>
> Jennifer,<br>
> I have attached a somewhat simplified version of the script I'm running.<br>
> The significant part of it is the loop (while a <= ensemble_size) ...<br>
> I put '!date' statements in to see how long each iteration of the loop<br>
> 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<br>
> about 60 seconds by the last few iterations of the loop. What I want to<br>
> know is 1) why is it taking longer despite the same code running, and 2) can<br>
> I reduce that time?<br>
><br>
> Jeff<br>
><br>
><br>
> On Thu, Jan 17, 2013 at 4:50 PM, Jennifer Adams <<a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a>> wrote:<br>
>><br>
>> Hi, Jeff --<br>
>> GRIB2 records are cached in case you want to reread data from the same<br>
>> grid more than once -- having grib records in the cache saves you the time<br>
>> of having to re-do the I/O and the uncompression. However, the cache can get<br>
>> big, and if you are pushing the memory limits of the your machine, you can<br>
>> clear the cache with the 'flush' command if you are sure you won't need any<br>
>> of the previously-read grids again. It is part of the 'reinit' command, and<br>
>> I just put it in there as a separate command in case it became necessary,<br>
>> but I don't think it will fix your slow-down problem. If you can provide a<br>
>> script that is as simple as possible but still illustrates the slow down, I<br>
>> will take a look.<br>
>> --Jennifer<br>
>><br>
>><br>
>><br>
>> On Jan 17, 2013, at 5:16 PM, Jeff Duda wrote:<br>
>><br>
>> What is the purpose of the command flush? I see from the documentation<br>
>> that it clears the GRIB2 cache. I think I understand what that basically<br>
>> means, but I wonder if it has implications in something I'm doing.<br>
>><br>
>> I'm running a series of complicated Grads scripts that read GRIB2 data and<br>
>> make a lot of plots. For some of my plots I am using the set defval<br>
>> command. One thing I've noticed while using this command is that the more<br>
>> times I run it in a loop of a Grads script, the longer it seems to take to<br>
>> run with each iteration. I know that sounds non-specific, so I can provide<br>
>> script code if anyone wants it, but I'm just feeling around here to see if<br>
>> the flush command may enable my scripts to run faster.<br>
>><br>
>> Jeff Duda<br>
>><br>
>> --<br>
>> Jeff Duda<br>
>> Graduate research assistant<br>
>> University of Oklahoma School of Meteorology<br>
>> Center for Analysis and Prediction of Storms<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>
>><br>
>> --<br>
>> Jennifer M. Adams<br>
>> IGES/COLA<br>
>> 4041 Powder Mill Road, Suite 302<br>
>> Calverton, MD 20705<br>
>> <a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a><br>
>><br>
>><br>
>><br>
>><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>
><br>
><br>
><br>
> --<br>
> Jeff Duda<br>
> Graduate research assistant<br>
> University of Oklahoma School of Meteorology<br>
> Center for Analysis and Prediction of Storms<br>
><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>
_______________________________________________<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>
</div></div></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>