[Paraview] Exodus weirdness
Rick Angelini
angel at arl.army.mil
Fri May 1 11:08:54 EDT 2009
I will re-investigate the data to determine if D3 and then CleanToGrid
does the trick.
Weirs, V Gregory wrote:
>
> OK, without D3 you will always see the processor boundaries. Paraview
> is see all the individual .exo files as independent, until you apply
> D3. CleanToGrid takes points that are essentially on top of each other
> and merges them. Nodes on processor boundaries are written to both
> exodus files, so before CleanToGrid you have, effectively, double
> valued nodes at processor boundaries; even though the nodes are at the
> same location, and the values are actually the same (if we wrote them
> out correctly) Paraview is probably trying to interpolate between them
> somehow.
>
> CellToPoint can hide the discrepancy by slightly smoothing the data
> when interpolating from cells to points.
>
> These are possible and sensible explanations, but without seeing the
> data we can’t be sure. Try D3 and CleanToGrid, and if you can still
> see processor boundaries we would want to look deeper, if that’s possible.
>
> Greg
>
> On 5/1/09 8:27 AM, "Rick Angelini" <angel at arl.army.mil> wrote:
>
> It's the boundaries from the original simulation. However, running
> through the D3 filter and then doing a cell2point seems to clean
> up the
> boundary edges.
>
> Thanks
>
>
> Moreland, Kenneth wrote:
> > I don’t recall seeing anything quite like that before. Are these
> > boundaries in question those in the original simulation (noted by the
> > file number) or the processes in your visualization (which can be
> > annotated with the Process Id Scalars filter)? Does running the data
> > through D3 help?
> >
> > -Ken
> >
> >
> > On 4/30/09 1:30 PM, "Rick Angelini" <angel at arl.army.mil> wrote:
> >
> > I am working with one of my customers viewing an Exodus dataset
> > generated by Alegra(?) using 256p. The dataset loads fine, but seems
> > to have an issue at the processor boundaries. When viewing the
> > dataset using something like a clip plane or isosurface, the data
> > seems
> > to be "slipped" (or offset) at each processor boundary - that is,
> > there
> > appears to be a hard edge at each processor boundary. Unfortunately,
> > I'm not able to post an image that represents the problem.
> >
> > I'm not familiar with the Exodus data format, but it looks like it
> > could
> > be an issue associate with ghost cells. Either there are no ghost
> > cells at the processor boundary layer, or they're possibly being
> > mismanaged? Curiously enough, this is the first time we've noticed
> > this problem after processing quite a few Exodus datasets. We're
> > using the latest production version of Paraview (3.4) and we've also
> > been able to duplicate the issue with other visualization tools,
> so we
> > think this is a problem with this particular Exodus dataset, if
> > not the
> > Exodus format in general.
> >
> > Any ideas?
> >
> >
> > _______________________________________________
> > 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
> >
> >
> >
> >
> > **** Kenneth Moreland
> > *** Sandia National Laboratories
> > ***********
> > *** *** *** email: kmorel at sandia.gov
> > ** *** ** phone: (505) 844-8919
> > *** web: http://www.cs.unm.edu/~kmorel
> <http://www.cs.unm.edu/%7Ekmorel> <http://www.cs.unm.edu/%7Ekmorel>
> >
> _______________________________________________
> 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
>
>
More information about the ParaView
mailing list