Re: Long Execution Times / Large WorkSpace Size

From: David Brown <dbrown_at_nyahnyahspammersnyahnyah>
Date: Tue Aug 28 2012 - 11:25:54 MDT

Hi Paul,
Sorry for the delay in answering. It sounds like you have solved most of the problem yourself. Yes it is good to make these Workspace values as large as you can comfortably afford given your hardware. Note that you can set them in an .hluresfile to make your values the default for all your plots. It may soon be time to revisit the hard-coded default for these resources. We have increased them several times over the years already.

It is true that RasterFill usually speeds up contour plotting, especially if there are many levels used. The default AreaFill plotting seems to be about O(n^2) for n = number of levels, whereas RasterFill speed is independent of the number of levels. However, if you are using 2D lat/lon coordinate arrays to plot over a map projection, RasterFill can also become very slow. Moreover, if the 2D coordinates have missing values, like many HDFEOS swath data sets do, this plotting method breaks down entirely. The cure for this problem is to switch to the triangular mesh plotting method. To do this, set the resource trGridType to "TriangularMesh". If you also set cnRasterSmoothingOn to True, then the plot will look very similar to an AreaFill plot. Unfortunately if you want to see the shape of the individual cells, they do not retain their original rectangular character because of the triangulation.

We are currently working on a new plotting method for discrete cells that should avoid most the drawbacks listed above. However, I cannot say for sure when it will be ready.
 -dave

On Aug 15, 2012, at 4:08 PM, Paul Scorer wrote:

> Have I missed the reply from Dave B (I have been on holiday), or has he
> not yet had a chance to look at this issue (having also been on
> holiday?)
>
> FWIW I have not had an issue with either of these problems since I added
>
> setvalues NhlGetWorkspaceObjectId()
> "wsMaximumSize": 1073741824 ; 1.0 GiB (0x40000000) WORKSTATIONSPACE
> "wsThresholdSize": 536870912 ; 0.5 GiB (0x20000000) WORKSTATIONTHRESHOLD
> end setvalues
>
> [And also specified RasterFill for all plots]
>
> BW
>
> PaulS
>
> On Mon, 2012-07-23 at 08:57 -0600, Mary Haley wrote:
>> Hi Paul,
>>
>> Dave Brown will need to answer the question about wsThresholdSize, and the scoping question. I admittedly had never heard of this resource.
>> Usually it's the wsMaximizeSize resource that we tell people to increase.
>>
>> Setting cnFillMode to "RasterFill" is the first thing we tell people who want to speed up their contour plotting. In the example that you pointed to below, were you using the default area fill? If so, then raster fill should help.
>>
>> You ask some good questions about memory. Once Dave answers some of them, I'll add them to our "memory issues" section in the FAQ.
>>
>> http://www.ncl.ucar.edu/FAQ/#mem_issues
>>
>> --Mary
>>
>> On Jul 20, 2012, at 8:20 AM, Paul Scorer wrote:
>>
>>> Hi,
>>>
>>> I am having trouble with very long plot times. It is a large (~200,000
>>> data points), and sometimes noisy, data set. An example is at
>>>
>>> http://rasp.inn.leedsmet.ac.uk/RASPtableGM8/RASPtableGM.html?date=20120720&param=wstar&time=1300&zoom=7&centre=52.555029,-0.613068
>>>
>>> This took NCL >15 mins to plot.
>>>
>>> I have found that RasterFill (rather than the default AreaFill) can
>>> dramatically speed things up for a contour plot, but I have not (yet)
>>> applied this to all parameters.
>>>
>>> I have also had a fatal Workspace Exceeded message. The machine has a
>>> reasonable amount of memory (18 GiB).
>>>
>>> It would seem from
>>> http://www.ncl.ucar.edu/Document/Graphics/Resources/ws.shtml
>>>
>>> that as soon as the total workspace exceeds wsThresholdSize (Default:
>>> 4194304 Bytes) the program "goes into swap", with obviously a massive
>>> penalty on runtime. Does this mean that increasing this value will defer
>>> this problem?
>>>
>>> Clearly, it is advantageous to delete variables that are no longer
>>> required: could you confirm that when a variable goes out of scope on
>>> return from a function or procedure it is automatically deleted?
>>>
>>> Thanks in advance for any pointers you can offer.
>>>
>>> Regards
>>>
>>> PaulS
>>>
>>> _______________________________________________
>>> ncl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Tue Aug 28 11:26:07 2012

This archive was generated by hypermail 2.1.8 : Tue Sep 11 2012 - 15:30:42 MDT