[Paraview] extract surface of multiblock mesh
Samuel Key
samuelkey at bresnan.net
Mon Apr 6 21:04:34 EDT 2009
Renato.
Spatial discrete algorithms based on the finite element method rarely if
ever require "ghost cells" extending beyond the physical boundary.
Algorithms based on finite difference technology almost always require a
layer of ghost cells around the analysis domain to allow the
point-centered algorithms to be computed. Data on the ghost cells and
ghost points is generally assigned to allow the finite difference
algorithm to execute.
For parallel domains, along the shared boundaries, the ghost cells must
acquire their data through swaps with adjacent domains.
The corresponding ghost cells on each subdomain usually are included in
the output results data for the subdomain, and the post-processors are
obliged to have algorithms and conventions to deal with the ghost cells
and their data.
In my humble opinion, the ghost cells and ghost points are not needed
for post-processing, but they are so "natural" to the finite difference
algorithm world that nobody would think to live without them.
However, ghost cells and ghost points and their data are needed to
restart a simulation and many developers want their restart files and
post-processing files to be one in the same file.
For what its worth,
Sam Key
Renato Elias wrote:
> Berk, forgive for delaying my response (I was out of my lab...)
>
> Just a silly question:
>
> What do you exactly mean by "Ghost cell"? This silly question is
> justified by the fact that I thought that ghost cells only make sense
> when we have subdomains _overlapped_. In these cases, the number of
> overlapped cell layers should (or could) be considered as "ghost level".
>
> In my case, the subdomains are not overlapped at all. They are just
> partitioned by Metis and the solver can deal with the computations
> without the need to use overlapped elements. Thus, if "ghost cells" can
> be simply defined by "cells somehow touching the parallel interface
> (even those not overlapped)" I think I could try tagging my parallel
> interface cells as "ghost level 0" to see what happens...
>
> Renato.
>
> On Sun, Apr 5, 2009 at 11:53 PM, Chris Kees
> <christopher.e.kees at usace.army.mil
> <mailto:christopher.e.kees at usace.army.mil>> wrote:
>
> Berk,
>
> Thanks for correcting me. I'll try adding the vtkGhostLevels to the
> XDMF and see how that goes.
>
> Chris
>
> On Apr 4, 2009, at 2:50 PM, Berk Geveci wrote:
>
> The right way to deal with this situation is to mark the ghost cells
> as ghost. If you create a cell array called vtkGhostLevels and
> assign
> 0 to inside cells and 1 to ghost cells, you should not need
> MergeBlocks or CleanToGrid. Note that this array has to be of type
> unsigned char. There are actual benefits to keeping ghost levels
> since
> some algorithms will produce better results.
>
> -berk
>
> On Thu, Apr 2, 2009 at 6:37 PM, Chris Kees
> <christopher.e.kees at usace.army.mil
> <mailto:christopher.e.kees at usace.army.mil>> wrote:
>
> I turned off the overlapping domain decomposition (ghost
> cells) for a simple
> problem and the sequence
>
> MergeBlocks->CleantoGrid->ExtractSurface->Clip
>
> shows just the physical boundary of the problem (clipped
> open so you can see
> inside). Also volume visualization and streamline
> calculation works with no
> processor boundary artifacts.
>
> >From what I understand, there are no filters in paraview
> or abstractions in
> the XDMF data model at this time that will allow paraview
> to read in
> overlapping blocks and really make use of the ghost cells
> correctly. For now
> truncating our output to only "owned" elements will solve
> our problems.
> Thanks again for the help.
>
> Chris
>
> On Mar 30, 2009, at 2:06 PM, Chris Kees wrote:
>
> Thanks for the help. I also tried suggestions from
> Paul, Ken, and Berk,
> but it does seem that I'm stuck right now unless I
> provide ParaView with
> more information. Since streamlines are computed
> correctly on the current
> multiblock mesh I just generated the mesh on a single
> processor and used
> ExtractSurface->Clip on that mesh to visualize the
> geometry around the
> streamlines from the multiblock grid.
>
> On the first method: Each of my UnstructuredGrids in the
> Multiblock Grid
> is a subdomain in an overlapping decomposition of the
> domain. Each of the
> subdomains has several elements of overlap (the layer of
> ghost cells is more
> than one element thick). Presumably the streamline
> generation works now on
> the multiblock grid because the overlap is loaded into
> ParaView. Is there a
> way I can just set a cell-centered attributed to
> identify the ghost cells so
> that surface extraction and volume visualization will
> work too? Currently
> volume visualization of the multiblock grid shows only a
> single subdomain
> and volume visualization after MergeBlocks shows the
> whole domain but with
> overlap regions being more opaque.
>
> On your other method, we have both the external boundary
> mesh and a
> pre-mesh polygonal representation of the boundaries
> available in the
> simulator. You are suggesting that I just dump one of
> those to a valid
> ParaView format as well, is that correct?
>
> Chris
>
> On Mar 30, 2009, at 9:14 AM, Jean Favre wrote:
>
> Chris Kees wrote:
>
>
> So far I've tried
> MergeBlocks->ExtractSurface->FeatureEdges->Clip and
> various permutations that I've seen in previous
> posts and the wiki,
> but I always end up with the surfaces on the
> interior of the tank as
> if it still sees each subdomain as a closed surface.
>
>
> In fact, it seems to me that ParaView does the best
> it can. Your
> unstructured mesh is partitioned in 512 pieces and
> [presumably], you did
> not specify ghost-cells at the partition boundaries.
> Without
> ghost-cells, ParaView has no information to help
> decide whether an
> outside face looks towards the outside world, or to
> another partition. I
> don't think any combination of filters would help
> you. Removing
> duplicate points may only remove duplicate fake
> boundaries, but these
> fake boundaries must be removed all together.
>
> I use two methods to achieve what you want.
> Ghost-cells, or another
> multi-piece object containing the different boundary
> types (solid,
> symmetries, inflow, outflow, etc) stored as
> vtkPolyData. These are read
> in from the models on disk.
>
> Jean --
> Swiss National Supercomputing Center
>
>
>
>
> _______________________________________________
> Powered by 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
>
>
> _______________________________________________
> Powered by 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
>
>
> _______________________________________________
> Powered by 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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Powered by 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 --------------
A non-text attachment was scrubbed...
Name: samuelkey.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090406/6814b9c5/attachment.vcf>
More information about the ParaView
mailing list