<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Arlindo,<br>
<br>
I eventually found cause of slow performance; I had constructs like
these:<br>
'define maxspeed = max(max(wspd,lon=-6.9,lon=36.5),lat=29.1,lat=58.0)'<br>
<br>
I used these to display some statistics. When I removed them it works
great over all domains. This still imply a question why it slows down
only 4km and 36km domain but does not slow down 12km domain. But if I
don't find an answer, I can live without that.<br>
<br>
6 seconds looks too short? Nope, grads 1.9 starts in very small
fraction of second on my system. Newest opengrads starts slower but
still not problem because I do loops inside grads script not in bash,
so grads is started/ended minimum number of times. As I said, it works
now excellent without constructs for finding maximum/minimum values
over domain area. It creates about 1000 png images per one domain in
something like minute or two which is negligible amount of time.<br>
<br>
Ivan<br>
<br>
<br>
<br>
Arlindo da Silva wrote:
<blockquote
 cite="mid:77fcd6b20909220713n30edf100i583af2986fe54795@mail.gmail.com"
 type="cite"><br>
  <br>
  <div class="gmail_quote">On Wed, Sep 2, 2009 at 1:51 PM, Ivan Toman <span
 dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:ivtoman@inet.hr">ivtoman@inet.hr</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Hello.
I have very strange issue and help is greatly appreciated.<br>
    <br>
I run WRF-NMM 36-12-4km nesting and after model finishes I forward<br>
output grib1 files to grads (1.9) from all three domains in successive<br>
order. First, 36km domain is processed in GrADS, when it finish 12km<br>
domain comes to work and when it finish, 4km go into GrADS at the end.<br>
    <br>
My problem is that GrADS has good performance only on 12km domain, on<br>
other domains it is very and extremely slow. These are times for<br>
creating map graphics from these domains:<br>
    <br>
36km - 40 seconds<br>
12km - 6 seconds<br>
4km - 105 seconds<br>
    <br>
It is very clear something very strange is going on. Why last domain<br>
gribs files needs almost two minutes to postprocess in GrADS, when<br>
intermediate domain gribs takes only 6 seconds to complete the same job?<br>
  </blockquote>
  <div>&nbsp;</div>
  <div>It has been my experience that you need to run these jobs at
least 20 times each and average the execution times in order to get
stable statistics. Also, process more than 1 time step at a time to
factor out the time it takes to start grads. An execution time of 6s is
too short not to get entagled with the usual latency of starting grads.</div>
  <div>&nbsp;</div>
  <div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Arlindo</div>
  <div>&nbsp;</div>
  <div>&nbsp;</div>
  <div>&nbsp;</div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Yes,
for all three domains is executed completely same .gs script,<br>
domain sizes are almost the same (in number of points), and GrADS don't<br>
output any error or similar unusual messages on any domain. There are no<br>
other CPU jobs that could slow down processing. GrADS use one CPU core<br>
at 100% all of time during this hanging.<br>
    <br>
These times are for only 6 output gribs (still testing), I need to<br>
extend forecast now to 60 hours, so there will be 10 times more data<br>
than now is, if now GrADS process for 105 seconds then it will work 17.5<br>
minutes to draw all needed maps from 4km domain?? This will become a<br>
serious concern then.<br>
    <br>
Please, can anybody help me to resolve this problem?<br>
    <br>
Thanks<br>
  </blockquote>
  </div>
  <br>
  <br clear="all">
  <br>
-- <br>
Arlindo da Silva<br>
  <a moz-do-not-send="true" href="mailto:dasilva@alum.mit.edu">dasilva@alum.mit.edu</a><br>
</blockquote>
<br>
</body>
</html>