> Dear NCL'ers,
>
> The research group I'm affiliated with is using NCL to generate
> 2D plots of analyses and forecasts from the ARPS weather model. Our
> system is set up so that an NCL script customized for a particular time,
> domain, etc. is created by a Perl script each time the model is run.
> After the NCL script is run and a NCGM file is produced, the NCGM file
> is converted to GIF or PNG files for display on the Web. In the past
> this approach has worked well, but recently we have been experiencing
> segmentation faults after adding vertical cross-sections into the mix.
>
> I have found that the segmentation faults go way when I cut out certain
> chunks of code, but they do not go away when I put in hardwired
> "if (False) then" statements that skip over the code. Given this
> behavior and the fact that the problem scripts we produce are about
> ~19,000 lines long, my question is: Is there a limit on the number of
> lines an NCL script can have? Could violating such a limit cause a
> segmentation fault?
>
> I'm also looking at other possible causes for the seg faults, but I
> am running out of culprits.
>
> Thanks,
>
> -Eric
>
Hi Eric,
I am not aware of any limits on the number of lines an NCL script can
have.
We have been investigating some potential memory issues with NCL, that
seem to cause the very kind of problem you are having. Sometimes
these problems cause NCL to core dump, or to say a variable isn't
defined when it very clearly is.
One possible culprit we've found is the deletion of NCL variables or
attributes that don't exist. If you are getting any warning messages
when you run your NCL script about attempting to delete a non-existent
variable, then try fixing this problem and see if it improves things.
One other thing to try is to improve the efficiency of your
code. We've found that big "do" loops (or several nested "do" loops)
can be memory killers in NCL.
Another memory killer is reordering dimensions that don't need to be
reordered. For example, some people will do something like:
temp_new = temp(time|:0,lev|:,lat|:,lon|:)
even if temp is already ordered time x lev x lat x lon. Folks do this
to make it clear in the code what order the dimensions are in. This is
a time consuming step, and if dimensions are really not being
reordered, then you are better off doing something like this:
temp_new = temp(0,:,:,:) ; temp is ordered time x lev x lat x lon
Meanwhile, I'm impressed that you have 19,000 lines of code! This is
some kind of user record. :-) I could attempt to look at pieces
of your code to see if there are ways to improve the efficiency. The
first thing I look at is do loops, and how they can be removed.
If you want to send me some, I'll be happy to look at them.
--Mary
_______________________________________________
ncl-talk mailing list
ncl-talk@ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
This archive was generated by hypermail 2b29 : Tue Oct 29 2002 - 15:34:18 MST