[Paraview] Problems with rendering/interacting with a large-ish volume data set...

Moreland, Kenneth kmorel at sandia.gov
Sat Dec 15 16:24:07 EST 2012


The first two problems that Brian reports come as no surprise to me and do not sound like bugs.  When you run either the clip filter or the threshold filter, an unstructured grid is generated by necessity.  An unstructured grid is a much less efficient representation than the image data you get from a raw file.  I would expect an unstructured grid representation of a 698x693x665 grid to take about 20 GB, so you can pretty much expect to run out of memory.

When dealing with large data like this, you should prefer slice over clip and contour over threshold.  These latter filters tend to generate much smaller and more manageable outputs.  The most recent ParaView User's Guide contains more details on these issues under the Modifying Data chapter.

http://www.paraview.org/Wiki/ParaView/UsersGuide/Recommendations

Now the final problem, where only half of the contour is rendered, sounds very strange and may well be a bug.  However, I don't think Sebastien will be able to replicate it with the zeros dataset (which will have no interesting contours).

-Ken

From: Sebastien Jourdain <sebastien.jourdain at kitware.com<mailto:sebastien.jourdain at kitware.com>>
Date: Saturday, December 15, 2012 9:11 AM
To: Brian Corrie <bcorrie at sfu.ca<mailto:bcorrie at sfu.ca>>
Cc: "paraview at paraview.org<mailto:paraview at paraview.org>" <paraview at paraview.org<mailto:paraview at paraview.org>>
Subject: [EXTERNAL] Re: [Paraview] Problems with rendering/interacting with a large-ish volume data set...

Thanks Brian,

I'll see what we can do about it.

Seb


On Fri, Dec 14, 2012 at 7:08 PM, Brian Corrie <bcorrie at sfu.ca<mailto:bcorrie at sfu.ca>> wrote:
Hi Seb,

I have asked the researcher, but in the mean time one can create the problem by simply generating a file of dimension 698x693x665 (Zeros.raw) with all Zeros in it. It seems to be independent of what is in the data file...

I load it with the "Raw (binary) Files" reader setting the dimensions as appropriate and scalar type to unsigned char. I then apply the Threshold filter as in the attached image and voila, I get the memory usage pattern from the second image.

I can give you the Zeros file, but it is probably faster to generate it than download. Let me know if you want the file... 8-)

Brian


On 14/12/2012 2:33 PM, Sebastien Jourdain wrote:
This definitely seems to be a set of bugs.
Can you share your data privately with us ? So we can track that down ?

Thanks,

Seb


On Fri, Dec 14, 2012 at 4:26 PM, Brian Corrie <bcorrie at sfu.ca<mailto:bcorrie at sfu.ca>
<mailto:bcorrie at sfu.ca<mailto:bcorrie at sfu.ca>>> wrote:

    Hello all,

    I was wondering if someone could provide me with some advice. I am
    trying to work with a large-ish (not really that large) volume data
    set. It is a 698x69x665 unsigned byte data set (~320MB).

    When working with Paraview (3.98.0-RC1) operations on the data set
    are quite cumbersome and relatively simple operations cause all
    sorts of havoc. I am wondering if there is something odd with my set
    up or are my expectations of interacting with a largeish volume data
    set too high. The specs for my workstation are:

    Windows 7 Pro, 64 bit, 2 X5690 processors (12 cores) at 3.47 GHz, 24
    GB of memory, nVidia Quadro 6000 graphics card. Pretty loaded...

    Rendering the data set with surface or volume is relatively
    interactive. When I try to apply other common filters (clip,
    threshold, isosurface) strange things occur:

    1) Applying a Clip filter causes Paraview to eventually consume 100%
    of the memory on my machine (24 GB). The computation of the filter
    runs forever, and I essentially have to kill off Paraview (the
    filter application doesn't complete after waiting several minutes).

    2) Applying a Threshold filter causes the same to occur. Basically
    causes memory usage to climb to 100% (24 GB). The filter never
    completes (at least not before my patience runs out 8-)

    3) Applying a Contour threshold works but strange things happen
    after isosurface creation. It creates a large polygon mesh (9M
    cells). With that said, memory footprint is still quite small. When
    interacting it renders using LOD so it is interactive. When I stop
    interacting it takes a couple of seconds to render at full
    resolution and another two seconds or so after it reaches full
    resolution LOD before I can interact with the application again.
    Approximately 4 seconds between stopping one interaction with the
    visualization (e.g. rotating the model) and being able to interact
    with the application again. Performance/interaction wise that is OK.
    The main problem is that only half the data set is rendered (see the
    image attached) at full LOD. There is no clip plane in the pipeline
    and yet half the data is missing in the display. The image should be
    a full sphere. When rendered at the lower LOD the entire data set is
    displayed, when rendered at full LOD the data is not.

    The above does not seem normal. The data set is large, but not huge.
    I certainly wouldn't expect the memory usage to spike to 24 GB and
    the rendering with the isosurface is very odd.

    Any advice from more experienced Paraview users? Should I get better
    performance/results? I would have thought so, are my expectations
    our to lunch? Or is this a bug that I should report?

    Brian









    _______________________________________________
    Powered by www.kitware.com<http://www.kitware.com> <http://www.kitware.com>


    Visit other Kitware open-source projects at
    http://www.kitware.com/opensource/opensource.html

    Please keep messages on-topic and check the ParaView Wiki at:
    http://paraview.org/Wiki/ParaView

    Follow this link to subscribe/unsubscribe:
    http://www.paraview.org/mailman/listinfo/paraview



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20121215/72a4fde4/attachment.htm>


More information about the ParaView mailing list