[Paraview] extract surface of multiblock mesh

[Renato Elias]

Yes, it's quite easy to implement (I just need to figure out how I do that
in Xdmf format... but it must be easy...)

Just to emphasize the subject -- or piss you off ;oP

The term "ghost" (some people use "halo". In portuguese it's "fantasma") is
suitable to define something that does not really exist -- or exists somehow
in another life ;o) -- in this sense, only cells (or nodes) that are not
really owned by a subdomain should be considered as ghosts. Consequently,
only cells (or nodes) that come from other parallel subdomains (in other
words, are somehow overlapped) should be considered as "ghost cells" or
"ghost nodes".

As I said, just trying to piss you off...

of course, I'm kidding....

Renato.

It explains why I never tried to define an array of ghost cells in my code.
They simply does not exist in my case...

On Mon, Apr 6, 2009 at 8:58 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> I did not mean ghost cells. I meant ghost points. If you were to mark
> the points at a shared interface as ghost (more appropriately
> duplicated), we can easily throw away all polygons that contain all
> duplicate points when extracting external surfaces. Even better, if we
> had an array that had values like:
>
> -1        : point not shared
> n >= 0 : point shared, owned by process n
>
> we could make bunch of filters work correctly - mainly statistics ones
> and the glyph filter. Is this something that is easy for your
> simulation to write?
>
> -berk
>
> On Mon, Apr 6, 2009 at 7:41 PM, Renato Elias <rnelias at gmail.com> 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> 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> 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
> >>>>>
> >>>>> 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
> >>>>
> >>
> >> _______________________________________________
> >> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090406/d13ab84e/attachment-0001.htm>