I have a point file in GRASS 5.7 (binaries from 22-07-2004 on Mac OSX
10.3.5). It displays fine in a UTM location.
If run d.vect.graph and I select a bar graph, all works fine.
If I select a pie chart, my computer slows to a crawl--all processes, not
just GRASS. Once I managed to get some of the pie graphs, including a partly
drawn graph before the computer dropped to low gear. I checked processes on
this once and GRASS was eating up nearly all the processing power and
available memory. I literally have to do a hard restart on the computer to
get control of it again.
I did NOT set a pie chart size column (it says optional). I left the rest at
the default or the settings that worked fine for bar graphs.
Any thoughts? Thanks.
Michael
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
I have a point file in GRASS 5.7 (binaries from 22-07-2004 on Mac OSX
10.3.5). It displays fine in a UTM location.
If run d.vect.graph and I select a bar graph, all works fine.
If I select a pie chart, my computer slows to a crawl--all processes,
not just GRASS. Once I managed to get some of the pie graphs,
including a partly drawn graph before the computer dropped to low
gear. I checked processes on this once and GRASS was eating up nearly
all the processing power and available memory. I literally have to do
a hard restart on the computer to get control of it again.
I did NOT set a pie chart size column (it says optional). I left the
rest at the default or the settings that worked fine for bar graphs.
Works for me in Linux.
Sounds like a memory leak, how many points are you displaying?
When you say "GRASS was eating up nearly all the processing power and
available memory" do you mean the d.vect.chart program specifically?
hint:
Try running 'top' in another terminal window. You can watch the
process go haywire and then press "k" and enter its PID to kill it.
'pkill d.vect.chart' might help too. 'xkill' is the most fun of course.
If it fails to die, you can send it stronger signals. see the kill help
pages.
I did what you suggested. When I run d.vect.chart using bar graphs, the
process (along with a dbf process) very briefly flashes in top then
disappears as it finishes.
However, if I do it with a pie chart it is a very different story. CPU use
zooms up to over 80% for awhile and memory use starts to climb rapidly.
RPRVT and RSIZE climbed to over 200 Mb (I have 512 Mb installed in my Mac
laptop and had several other apps running, but paused and using limited
RAM). VSIZE climbed to over 530 Mb. As memory use climbed, CPU use dropped
way down (0.8%) and stayed low from then on. Memory use stabilized at around
230Mb for RPRVT and RSIZE and 534Mb for VSIZE.
I had to kill it. Kill worked OK (i.e., no need for xkill), though
everything was slow as molasses. I went ahead and quit X11 then. Things seem
to have gotten back to normal now, without rebooting.
So what is going on? Is this happening to anyone else? Is it just Mac's? Is
it just my system?
Cheers
Michael
On 8/31/04 12:53 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
I want to re-report a problem with d.vect.graph.
I have a point file in GRASS 5.7 (binaries from 22-07-2004 on Mac OSX
10.3.5). It displays fine in a UTM location.
If run d.vect.graph and I select a bar graph, all works fine.
If I select a pie chart, my computer slows to a crawl--all processes,
not just GRASS. Once I managed to get some of the pie graphs,
including a partly drawn graph before the computer dropped to low
gear. I checked processes on this once and GRASS was eating up nearly
all the processing power and available memory. I literally have to do
a hard restart on the computer to get control of it again.
I did NOT set a pie chart size column (it says optional). I left the
rest at the default or the settings that worked fine for bar graphs.
Works for me in Linux.
Sounds like a memory leak, how many points are you displaying?
When you say "GRASS was eating up nearly all the processing power and
available memory" do you mean the d.vect.chart program specifically?
hint:
Try running 'top' in another terminal window. You can watch the
process go haywire and then press "k" and enter its PID to kill it.
'pkill d.vect.chart' might help too. 'xkill' is the most fun of course.
If it fails to die, you can send it stronger signals. see the kill help
pages.
Hamish
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
I did what you suggested. When I run d.vect.chart using bar graphs,
the process (along with a dbf process) very briefly flashes in top
then disappears as it finishes.
what does the data look like?
i.e. **how many points in the data file**, what kind of data (integer,
floating point, etc)?
Can you try it with a different points file?
Vect_destroy_line_struct() is called to free the memory put aside for
each polygon as they draw....
Sorry. Forgot to answer the second part of your prior message. There are 154
points in the file. This doesn't seem like very many to me. I had set the
region to only show <10. But it seems that d.vect.chart may not respect
region settings. There are string, double precision, and integer fields in
the database (I list the output of v.info below). To keep it all simple, I
was sticking to integer values (range 0-100). I don't have another point
file handy to try it on, but could make one.
Michael
On 8/31/04 11:08 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
I did what you suggested. When I run d.vect.chart using bar graphs,
the process (along with a dbf process) very briefly flashes in top
then disappears as it finishes.
what does the data look like?
i.e. **how many points in the data file**, what kind of data (integer,
floating point, etc)?
Can you try it with a different points file?
Vect_destroy_line_struct() is called to free the memory put aside for
each polygon as they draw....
Hamish
- - - v.info output - - -
v.info map=Polop_anal field=1
+--------------------------------------------------------------------------
--+
| Layer: Polop_anal Organization:
|
| Mapset: grass57test Source Date:
|
| Location: Spain Name of creator:
|
| Database: /Users/Shared/grassdata/
|
| Title:
|
| Map Scale: 1:1
|
| Map format: native
|
|--------------------------------------------------------------------------
--|
| Type of Map: Vector (level: 2)
|
|
|
| Number of points: 154 Number of areas: 0
|
| Number of lines: 0 Number of islands: 0
|
| Number of boundaries: 0 Number of faces: 0
|
| Number of centroids: 0 Number of kernels: 0
|
|
|
| Map is 3D: 0
|
| Number of dblinks: 1
|
|
|
| Projection: UTM (zone 30)
|
| N: 4286172.730 S: 4282702.870
|
| E: 713632.350 W: 708309.400
|
| B: 0.000 T: 0.000
|
|
|
| Digitize threshold: 0.00000
|
| Comments:
|
|
|
+--------------------------------------------------------------------------
--+
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
I did what you suggested. When I run d.vect.chart using bar graphs, the
process (along with a dbf process) very briefly flashes in top then
disappears as it finishes.
However, if I do it with a pie chart it is a very different story. CPU use
zooms up to over 80% for awhile and memory use starts to climb rapidly.
RPRVT and RSIZE climbed to over 200 Mb (I have 512 Mb installed in my Mac
laptop and had several other apps running, but paused and using limited
RAM). VSIZE climbed to over 530 Mb. As memory use climbed, CPU use dropped
way down (0.8%) and stayed low from then on. Memory use stabilized at around
230Mb for RPRVT and RSIZE and 534Mb for VSIZE.
I had to kill it. Kill worked OK (i.e., no need for xkill), though
everything was slow as molasses. I went ahead and quit X11 then. Things seem
to have gotten back to normal now, without rebooting.
So what is going on? Is this happening to anyone else? Is it just Mac's? Is
it just my system?
From display/d.vect.chart/pie.c:
double a, end_ang, ang, tot_sum, sum, step, r;
while ( 1 ) {
if ( a > end_ang ) a = end_ang;
x = cx + r * cos ( a );
y = cy + r * sin ( a );
Vect_append_point ( Points, x, y, 0);
if ( a == end_ang ) {
ang = end_ang;
break;
} else {
a += step;
}
}
One possiblity is that the "a == end_ang" test never becomes true
(even after the "a = end_ang" assignment), so the loop runs forever.
On Wed, September 1, 2004 8:29, Glynn Clements said:
Michael Barton wrote:
I did what you suggested. When I run d.vect.chart using bar graphs, the
process (along with a dbf process) very briefly flashes in top then
disappears as it finishes.
However, if I do it with a pie chart it is a very different story. CPU
use
zooms up to over 80% for awhile and memory use starts to climb rapidly.
RPRVT and RSIZE climbed to over 200 Mb (I have 512 Mb installed in my
Mac
laptop and had several other apps running, but paused and using limited
RAM). VSIZE climbed to over 530 Mb. As memory use climbed, CPU use
dropped
way down (0.8%) and stayed low from then on. Memory use stabilized at
around
230Mb for RPRVT and RSIZE and 534Mb for VSIZE.
I had to kill it. Kill worked OK (i.e., no need for xkill), though
everything was slow as molasses. I went ahead and quit X11 then. Things
seem
to have gotten back to normal now, without rebooting.
So what is going on? Is this happening to anyone else? Is it just Mac's?
Is
it just my system?
From display/d.vect.chart/pie.c:
double a, end_ang, ang, tot_sum, sum, step, r;
while ( 1 ) {
if ( a > end_ang ) a = end_ang;
x = cx + r * cos ( a );
y = cy + r * sin ( a );
Vect_append_point ( Points, x, y, 0);
if ( a == end_ang ) {
ang = end_ang;
break;
} else {
a += step;
}
}
One possiblity is that the "a == end_ang" test never becomes true
(even after the "a = end_ang" assignment), so the loop runs forever.
The problem happens to me when for at least one spatial entity all the
columns used for the pie chart contain zero. Michael can you confirm this
? Is this linked to the above loop ?
Indeed, there are some cases for which all columns used in the pie chart
would be zero. Do I need to filter these out? Perhaps the pie chart
algorithm should automatically filter these out if it is problematic??
Michael
On 9/21/04 2:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
From display/d.vect.chart/pie.c:
double a, end_ang, ang, tot_sum, sum, step, r;
while ( 1 ) {
if ( a > end_ang ) a = end_ang;
x = cx + r * cos ( a );
y = cy + r * sin ( a );
Vect_append_point ( Points, x, y, 0);
if ( a == end_ang ) {
ang = end_ang;
break;
} else {
a += step;
}
}
One possiblity is that the "a == end_ang" test never becomes true
(even after the "a = end_ang" assignment), so the loop runs forever.
The problem happens to me when for at least one spatial entity all the
columns used for the pie chart contain zero. Michael can you confirm this
? Is this linked to the above loop ?
Moritz
______________________________
Michael Barton, Professor & Curator
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
Indeed, there are some cases for which all columns used in the pie chart
would be zero. Do I need to filter these out? Perhaps the pie chart
algorithm should automatically filter these out if it is problematic??
The algorithm needs to iterate for a fixed number of steps. Try the
attached patch.
On Tue, September 21, 2004 20:03, Glynn Clements said:
Michael Barton wrote:
Indeed, there are some cases for which all columns used in the pie chart
would be zero. Do I need to filter these out? Perhaps the pie chart
algorithm should automatically filter these out if it is problematic??
The algorithm needs to iterate for a fixed number of steps. Try the
attached patch.
This seems to do the trick. Everything works perfectly here now.
Thanks !
Moritz
--
Glynn Clements <glynn.clements@virgin.net>
--- pie.c~ Sun Sep 5 08:20:31 2004
+++ pie.c Tue Sep 21 18:58:25 2004
@@ -11,7 +11,7 @@
int
pie ( double cx, double cy, int size, double *val, int ncols, COLOR
*ocolor, COLOR *colors )
{
- int i, j;
+ int i, j, n;
double a, end_ang, ang, tot_sum, sum, step, r;
double x, y;
struct line_pnts *Points;
@@ -36,20 +36,15 @@
if (val[0] != tot_sum) /* all in one slice, don't draw line to center */
Vect_append_point ( Points, cx, cy, 0);
- a = ang;
- while ( 1 ) {
+ n = (int)ceil((end_ang - ang) / step);
+ for (j = 0, a = ang; j <= n; j++, a += step)
+ {
if ( a > end_ang ) a = end_ang;
x = cx + r * cos ( a );
y = cy + r * sin ( a );
Vect_append_point ( Points, x, y, 0);
-
- if ( a == end_ang ) {
- ang = end_ang;
- break;
- } else {
- a += step;
- }
}
+ ang = end_ang;
if (val[0] != tot_sum)
Vect_append_point ( Points, cx, cy, 0);