Hi Lezlie,
If your points are not truly random, but you know how
they arranged and how they can be organized into
triangles (or even a grid), then you write your own
text reader and construct your own DelaunayCustom for
them to express your organization into triangles (or
if they are in a grid, construct a GriddedSet).
But if they are random, you are stuck with Delaunay
performance.
Good luck,
Bill
On Fri, 8 Apr 2005, Lezlie Fort wrote:
> Hi Bill,
>
> 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.
>
> Thanks again!
> lzf
>
> 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:
> >
> >
> >
> >>Hi Lezlie,
> >>
> >>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).
> >>
> >>Bill
> >>
> >>On Thu, 7 Apr 2005, Lezlie Fort wrote:
> >>
> >>
> >>
> >>>Hello,
> >>>
> >>>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?
> >>>
> >>>Thanks alot,
> >>>lzf
> >>>
> >>>
> >>>
> >>
> >>
>
>
>
