NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: p.s., Re: VisAD 3D surface graph performance

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
> >>>
> >>>
> >>>
> >>
> >>
>
>
>


  • 2005 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: