[Paraview] Parallel unfriendly filters?

[Moreland, Kenneth]

David,

Yes, I figured that's what you meant by ghost zones. My point is that you can leave these in for the contour operation. Because you have overlapping cells, the processors on each side of the boundary will compute the same data at the boundary.

The trick is to carry avtGhostZones all the way through the calculations. If done correctly, then the surface computed by Contour will have avtGhostZones cell data, and you can strip out the ghost zones in the contour. The only caveat is to be careful with the Cell Data to Point Data filter because the avtGhostZones array will be invalid if converted from cells to points. You can tell the Cell Data to Point Data filter to just pass the cell data.

-Ken

From: ParaView <paraview-bounces at paraview.org<mailto:paraview-bounces at paraview.org>> on behalf of David Ortley <djortley at gmail.com<mailto:djortley at gmail.com>>
Date: Monday, February 8, 2016 at 1:56 PM
Cc: "paraview at paraview.org<mailto:paraview at paraview.org>" <paraview at paraview.org<mailto:paraview at paraview.org>>
Subject: [EXTERNAL] Re: [Paraview] Parallel unfriendly filters?

Kenneth:

The ghost zones are the contents of the ghost zones stored from the calculation. They overlap into the hydro from neighboring processors (the silo library stores a block per processor the way we're using it in our code.)  If I leave them in there, I get artifacts.  I'm actually thresholding out a variable called 'avtGhostZones', which the silo libraries call the stored ghost zone values.


Dan:

Cell Data to Point Data is the only way I know of to activate the contour filter for silo files.  The results are stored in cell arrays, which apparently don't activate the contour filter.  I stumbled upon using Cell Data to Point Data by accident, so if there's a better way to do this, I'm open to it.


Thanks.

-David Ortley

On Mon, Feb 8, 2016 at 1:35 PM, Moreland, Kenneth <kmorel at sandia.gov<mailto:kmorel at sandia.gov>> wrote:
Have you tried doing the threshold last (after the contour) rather than first? Generally, ParaView relies on ghost zones (cells) to avoid artifacts across process boundaries.

-Ken


From: ParaView <paraview-bounces at paraview.org<mailto:paraview-bounces at paraview.org>> on behalf of David Ortley <djortley at gmail.com<mailto:djortley at gmail.com>>
Date: Monday, February 8, 2016 at 1:14 PM
To: "paraview at paraview.org<mailto:paraview at paraview.org>" <paraview at paraview.org<mailto:paraview at paraview.org>>
Subject: [EXTERNAL] [Paraview] Parallel unfriendly filters?

I'm running Paraview in client/server mode with the server running on an HPC platform across multiple nodes.

My input is a multi-block silo file that contains ghost zone information.  The way I do a seamless contour when visualizing on my workstation is to do the following:

Load the silo file
    -> Threshold out the ghost zones (threshold filter)
        -> Merge the blocks
            -> Cell data to point data
                -> Contour

This works well enough when on a single machine.  But when visualizing client/server with the server running across multiple nodes, there appear seams on the contours.

Is this an expected behavior given my setup?  Are any of the filters that I listed above (Threshold, Merge Blocks, Cell data to point data, and Contour) not fully implemented in parallel yet?

nb - I've not spent a lot of time trying to debug the problem, so I don't know if the problem exists when a server is running on a single node only.  It looks like something that is happening at node boundaries, but I could be wrong and it could be a per/processor thing.

Thanks.

-David Ortley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160208/2691bf75/attachment.html>