Thanks so much for your reply. I should preface my response by
indicating my hope that you saw the second addendum message that I sent
out. The number in my initial mail (380) referred to a single "group"
of Depth parameters. There were 20 such groups in my data set, so the
true number of points was 7600. But even that number is small compared
to the 42000 that you mentioned in your first reply! I think that you
nailed my problem, though, in your p.s. I am using the TextAdapter to
read in my data files, and I looked at TextAdapter.java to see what was
going on. Sure enough, based on my defined math type, it is creating an
Irregular set using the Delaunay algorithm. I did some brief research
online and found out that performance of Delaunay can be as high as
O(n^2), so that helped me to understand what was happening. I read one
post where someone was plotting over 100,000 points using the algorithm,
and had to wait for over 8 hours for the calculations to complete. I
read about other algorithms out there, but Delaunay seems to be one that
is prevalent. I feel better just having an explanation for what I am
seeing. If I have time, I might do a little more research into the
Delaunay algorithm. One post suggested that a way to reduce performance
time is to pre-sort one of the vectors involved in the calculations (the
vector that is associated with the most dramatic changes in data
values). They indicated that such a step could result in a performance
savings of 25%. But, like I said, this is just cursory research.
At any rate, I have been very pleased with VisAD, and this is really the
only issue that I've run into (although I've had a few questions along
the way, as my recent posts will attest ;). And it's not really an
issue, in the long run. For large data sets I can always plot 3D line
graphs, which are extremely quick.
Bill Hibbard wrote:
Another possibility is that you are constructing an
IrregularSet in your data, which can be slow. But
Test29 constructs and displays a colored surface from
an Irregular2DSet of 1024 points in just a few seconds.
On Fri, 8 Apr 2005, Bill Hibbard wrote:
Something's wrong here. Lots of the test programs in the
visad/examples directory render surfaces with RGB mappings
that are much larger than 380 points, and much quicker than
a minute even on my old 500 MHz laptop with a bad old
graphics card. You might try running Test33, Test37 and
Test61 (its volume rendering is made of a series of flat
surfaces with a total of over 42000 points, and runs in a
few seconds on my laptop).
On Thu, 7 Apr 2005, Lezlie Fort wrote:
I have a VisAD performance question.
I've written recently before - indicating that I am creating a number of
different graphs using ASCII space-separated input files. One of the
graph types that I'm generating is a "4D" surface graph. Yesterday, I
ran a case with the following math type: (Time,Depth)->(Speed,col),
where "col" is a fourth dimension that I have mapped to Display.RGB.
The case that I ran had about 380 data points in all four vectors, and
I found that on my Linux box (nVidia GeForce FX graphics card, 1.5GHz
processor, 512M RAM), it took about 1.5 minutes for the graph to
generate. On my Windows XP box (2.27 GHz processor, 512M RAM, Intel
82845G video board - Open GL version of Java3D), it took about 3.5
minutes to generate. I ran additional cases where I increased the data
size, and ended up killing the graph-generation process after 5 minutes
of intensive disk-chunking. I know that 3D surface generation is very
computation-intensive (3D line graphs of the same data come up almost
instantly), but I was wondering if these performance numbers that I'm
seeing are typical. I've tried to find information on other graphing
packages (eg: MatLab) to determine what kind of performance one would
expect with them, but seem to have encountered varied information. Any
ideas on whether what I'm seeing is typical, or is there perhaps
something that I am doing extremely incorrectly?