<div dir="ltr"><div><div><div><div><div><div>Josh,<br><br></div> Assuming the problem is not with your scripts, then<br></div>what could go wrong with GrADS?<br><br></div>1) Many years ago, we had a busy web server running grads<br></div>to produce user-defined plots. Therefore at that time, a single<br></div><div>user was running many grads sessions at once with no problems.<br></div>Therefore, it may be a new problem or a problem with your system.<br><br></div><div>a) Are your scripts running GrADS in "batch" mode?<br></div><div>There may be some system limitation with too many<br></div><div>display windows. (grads -b)<br><br></div><div>b) Are you running out of memory? <br></div><div><div><br></div><div>The script "<a href="http://g2grb.gs">g2grb.gs</a>" is an easy-to-use script to convert<br></div><div>a gridded field into grib2. It is slow because it does<br></div><div>repeated generation of the template. Sounds<br></div><div>like you trying to speed up the conversion into grib by<br></div><div>running your job into many pieces at one time. A<br></div><div>conversion of a binary/ieee file into grib2 can be done<br></div><div>outside of grads.<br><br></div><div>Version 1<br><br></div><div>step 1: generate template file (see <a href="http://g2grb.gs">g2grb.gs</a>)<br></div><div>step 2: generate ieee/bin stream (no header/trailer) or sequential (f77<br></div><div> header trailer) data file. <br></div><div>step 3: generate metadata file (one line per field) (see your script)<br></div><div>step 4: run wgrib2 with template file, ieee file and metadata file<br></div><div> and you have a grib file.<br><br></div><div>Version 2<br></div><div> use wgrib2api<br> <a href="http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/wgrib2api.html">http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/wgrib2api.html</a><br></div><div> The fortran version is good to go. The C version is 90% ready to release.<br><br></div><div>Wesley<br></div><div><br><br></div><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 6:02 PM, Josh Cohen <span dir="ltr"><<a href="mailto:development@innovationwx.com" target="_blank">development@innovationwx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Wesley,<div><br></div><div>I tried doing that but to no avail. My guess is something is going on with my installation/internals of GrADS. I come from more of a programming/computer science background, so when I saw that my code had no race conditions but still broke when running in parallel, I immediately thought it must have been something I wasn’t familiar with GrADS (as GrADS from my point of view is not intuitive at all). I appreciate your advice.</div><div><br></div><div>Thank you,</div><div><br></div><div>Josh<br><blockquote type="cite"><pre style="white-space:pre-wrap;font-variant-ligatures:normal">Josh,
Problems in running jobs in parallel usually are caused by a file that is
being "shared" when it shouldn't be.
<a href="http://g2grb.gs" target="_blank">g2grb.gs</a> uses temporary files but there names are based on the output
file which is different in the parallel runs.
wgrib2 doesn't make temporary files and doesn't lock files. So I don't
know what is causing your problem. My suggestion is turn each of the
parallel jobs in its own directory.
Wesley
</pre></blockquote><div><pre style="white-space:pre-wrap;font-variant-ligatures:normal"><br></pre></div></div></div><br>______________________________<wbr>_________________<br>
gradsusr mailing list<br>
<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" rel="noreferrer" target="_blank">http://gradsusr.org/mailman/<wbr>listinfo/gradsusr</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div>