[ncl-talk] RPRAM - ALGORITHM FAILURE reemerges

Dennis Shea shea at ucar.edu
Wed Feb 28 10:42:05 MST 2018


>From a 'science/statistics' point of view, once different structures [EOF
patterns] are not "significantly different" from adjacent patterns, then
you are looking at sampling issues.

Because atmosphere/ocean/geophysical data most-often have 'red' spectrums,
the number of significant patterns rarely exceeds (say) 3 or 4  EOFs.

Likely, at EOF 30, almost every other grid point will be oscillating about
the zero contour. Hence, **lots of contours**. From a science/statistics
point of view they are uninterpretable. Well, except to say they are
'sampling noise.'

NCL has a function which will use North's 'rule-of-thumb' to assess EOF
significance.

http://www.ncl.ucar.edu/Document/Functions/Contributed/eofunc_north.shtml

==
Please see:

http://www.ncl.ucar.edu/Applications/eof.shtml
Example 6

Cheers



On Wed, Feb 28, 2018 at 9:51 AM, Mary Haley <haley at ucar.edu> wrote:

> Hi Tobias,
>
> Thanks for providing the files. I just ran your script with both NCL
> V6.4.0 and our 6.5.0 development version and it didn't produce any errors.
>
> What kind of system are you running on? I ran this from a MacOS system.
>
> This kind of error seems to happen when you have small plots that have
> either lots of contours or very "twisty" contours.  As you described,
> sometimes tweaking things slightly can make the problem go away.
>
> I don't know what you've tried so far, but here are some suggestions:
>
> 1) Use raster contours instead of smooth contours, by setting:
>
> res at cnFillMode = "RasterFill"
>
> This can sometimes make the plotting go faster, too. However, you will
> need to look to the contours to see if they are too blocky looking for your
> purpose.
>
> ​2) Make
>  the
> ​panel ​
> plots slightly larger, as this gives NCL more room to draw the contours
> and hence less likely to run into contour drawing problems.  The way to do
> this is by setting gsnPanelXWhiteSpacePercent and
> gsnPanelYWhiteSpacePercent to smaller numbers, like 1 or 2.
>
> ​If you find that the plots are getting too close in this case, then you
> might consider getting rid of the gsnLeftString title, since it's the same
> for every plot and you already have part of that title as the main title
> for the panel main string. You can then set the "exp var = x.xx" string as
> a gsnCenterString instead of a gsnRightString:
>
>   res at gsnLeftString = ""
>   do ii=10,19
> ;
>> res at gsnRightString = "exp var = "+sprintf("%4.2f",eof at pcvar(ii))
>
> ​  ​
> res at gsnCenterString = "exp var = "+sprintf("%4.2f",eof at pcvar(ii))
> ​    . . .​
>
> ​  end do​
>
> ​3) If you can stand to have a non-equal number of plots per row, then
> draw the plots in a 4 x 3 configuration instead of a 2 x 5 configuration,
> which gives them more room.  You can force the last plot to be
> left-justified by setting pres at gsnPanelCenter = False:
>
> pres at gsnPanelCenter = False
> gsn_panel(wks,plot(0:9),(/4,3/),pres)
>
>
> ​If none of this helps, please write back to ncl-talk and let us know.
>
> [ I see that Rick just responded and said he could reproduce your error.
> I'll check with him about why my environment is different than his. ]
>
> --Mary
>
>
>
> On Wed, Feb 28, 2018 at 5:13 AM, Tobias Kleine <tobias.kleine at gmx.net>
> wrote:
>
>> Hi there,
>>
>> I am currently working on EOF analysis of SSTs in the North Atlantic.
>> While plotting the first 30 EOFs (polar plot) I for the first time
>> encountered the apparently infamous RPRAM - ALGORITHM FAILURE error. I
>> quickly found out that often enough it has something to do with the contour
>> intervals or levels and thus played around with that for a while. But so
>> far I've not managed to plot all my 30 EOF patterns with one setting for
>> the contour levels and making all plots actually get drawn by ncl.
>>
>> I also found out, that the ARSCAM/ARPRAM bug has (according to
>> http://www.ncl.ucar.edu/prev_releases.shtml#ARSCAMARPRAMBugFixed5.2.1)
>> been fixed with NCL5.2.1 . So I wondered my problem might be or if this is
>> the reemergence of it?
>>
>> I have uploaded my data file and the script to the incoming ftp directory
>> under the following names:
>> predictor01_sst_oct.nc (data, 50MB)
>> SUPPORT_analyze_eof_sst.ncl (script, 4KB)
>>
>> -I am running ncl version 6.4.0
>> -System type (don't 100% which part of this is relevant) Linux mlogin105
>> 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Dec 28 20:15:47 EST 2017 x86_64
>> x86_64 x86_64 GNU/Linux
>> - error message:
>> fatal:ContourPlotDraw: ARPRAM - ALGORITHM FAILURE
>> fatal:ContourPlotDraw: ARPRAM - ALGORITHM FAILURE
>> fatal:ContourPlotDraw: ARSCAM/ARPRAM - ALGORITHM FAILURE
>> fatal:ContourPlotDraw: draw error
>> fatal:ContourPlotDraw: draw error
>> fatal:PlotManagerDraw: error in plot draw
>> fatal:_NhlPlotManagerDraw: Draw error
>>
>> Thanks for considering to help me out on this issue.
>> I hope I did not forget to submit relevant information.
>>
>> All the best
>> Tobias Kleine
>> Institut für Meereskunde
>> Universität Hamburg, Germany
>>
>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> ncl-talk at ucar.edu
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>>
>
> _______________________________________________
> 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/20180228/86ac3552/attachment-0001.html>


More information about the ncl-talk mailing list