[ncl-talk] Code Compiling Extremely Slowly

[Rick Brownrigg]

Hi Zach,

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.

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:

ncl 1> time = (/50C,48C,49C,57C, 48C, 56C, 48C, 54C/)  ; funky notation for
character literals; this should be today's date: 20190806
ncl 2> print("year = " + tointeger(str_get_cols(time,0,3)))
ncl 3> print("mon = " + tointeger(str_get_cols(time,4,5)))
ncl 4> print("day = " + tointeger(str_get_cols(time,6,7)))

This works, but I don't know if its an improvement; it issues warnings to
the effective of:

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

I don't know if, under the hood, "coercion" is more efficient than straight
up conversion.

I am not qualified to address the science question about the divergence of
the curves.

Good luck!
Rick


On Tue, Aug 6, 2019 at 5:50 PM Zach Rieck via ncl-talk <ncl-talk at ucar.edu>
wrote:

> To Whom it May Concern-
>
> 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.
>
> 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.
>
> Thanks in advance for the help!
>
> Respectfully,
>
> -Zach Rieck
> zrr817 at gmail.com
> (513)-502-5652
> _______________________________________________
> ncl-talk mailing list
> ncl-talk at ucar.edu
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20190806/b4d4d8e0/attachment.html>