<div dir="ltr"><div>OK, hopefully someone else can weigh in here -- I don't see anything auspicious about lines 70-77, but I'm not expert with those data...</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 6, 2019 at 8:50 PM Zach Rieck <<a href="mailto:zrr817@gmail.com">zrr817@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Rick!<div><br></div><div>I think the thing that slows it down most is the do loop from 70-77 for some reason. Not sure if they arguments I'm using could be more specific to avoid pulling in so much data. Hard to tell, and I agree I wish that NCL was more efficient with that! Us programmers who are used to doing loops really need them.</div><div><br></div><div>I got the divergence issue figure out, just had a -1 inside a parenthesis when it should have been outside.</div><div><br></div><div><div><div dir="ltr" class="gmail-m_4954655856518945165gmail_signature"><div dir="ltr">-Zach Rieck<div><a href="mailto:zrr817@gmail.com" target="_blank">zrr817@gmail.com</a></div><div>(513)-502-5652</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 6, 2019 at 8:36 PM Rick Brownrigg <<a href="mailto:brownrig@ucar.edu" target="_blank">brownrig@ucar.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Zach,</div><div><br></div><div>Just a comment and a conjecture: NCL's string processing is notoriously inefficient when the number of strings involved gets large (something I'd dearly loved to have fix, but...). With that in mind, I wonder if the string processing around lines 22-41 might be the problem, in which you convert the variable Time coming out of the WRF files to strings, and then use the str_get_cols() function to pick out pieces of year/month/day/etc. <br></div><div><br></div><div>I don't really know much about it, but as far as I can tell, the Time variable from a WRF file is character[*][*]? Converting sequences of characters to integers does not seem to be directly supported, but you might try something like:</div><div><br></div><div>ncl 1> time = (/50C,48C,49C,57C, 48C, 56C, 48C, 54C/) ; funky notation for character literals; this should be today's date: 20190806<br>ncl 2> print("year = " + tointeger(str_get_cols(time,0,3)))<br>ncl 3> print("mon = " + tointeger(str_get_cols(time,4,5)))<br>ncl 4> print("day = " + tointeger(str_get_cols(time,6,7)))</div><div><br></div><div>This works, but I don't know if its an improvement; it issues warnings to the effective of:<br></div><div><br></div><div>warning:Argument 0 of the current function or procedure was coerced to
the appropriate type and thus will not change if the function or
procedure modifies its value<br></div><div><br></div><div>I don't know if, under the hood, "coercion" is more efficient than straight up conversion.</div><div><br></div><div>I am not qualified to address the science question about the divergence of the curves.</div><div><br></div><div>Good luck!</div><div>Rick</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 6, 2019 at 5:50 PM Zach Rieck via ncl-talk <<a href="mailto:ncl-talk@ucar.edu" target="_blank">ncl-talk@ucar.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">To Whom it May Concern-<div><br></div><div>I have been having an issue with a plot I have generated with this code file, and I need to be able to quickly troubleshoot the data it is pulling in. My code seems to be doing exactly what I want, but I'm curious if there's anyway to make it run faster/more efficiently? I know this may difficult since I'm having to skip over a bunch of time periods and organize a lot of data into different sized groups, so if the answer is I can't, that's fine. </div><div><br></div><div>I've attached the figure in question as well just in case you see anything that might be causing the spread near the top of the figure. I've gone through my code very carefully, and I'm pretty sure it's an issue with the dataset, but if you notice anything else I can try fixing please let me know.</div><div><br></div><div>Thanks in advance for the help!</div><div><br></div><div>Respectfully,</div><div><br clear="all"><div><div dir="ltr" class="gmail-m_4954655856518945165gmail-m_5818544005662226521gmail-m_-8683510948150971556gmail_signature"><div dir="ltr">-Zach Rieck<div><a href="mailto:zrr817@gmail.com" target="_blank">zrr817@gmail.com</a></div><div>(513)-502-5652</div></div></div></div></div></div>
_______________________________________________<br>
ncl-talk mailing list<br>
<a href="mailto:ncl-talk@ucar.edu" target="_blank">ncl-talk@ucar.edu</a><br>
List instructions, subscriber options, unsubscribe:<br>
<a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" rel="noreferrer" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a></blockquote></div>
</blockquote></div>
</blockquote></div>