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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
begin:vcard
fn:Samuel Key
n:Key;Samuel
org:FMA Development, LLC
adr:;;1005 39th Avenue NE;Great Falls;Montana;59404;USA
email;internet:[email protected]
title:Senior Software Architect
tel;work:(406) 952-1543
tel;home:(406) 952-1543
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
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
