[Paraview] Exodus weirdness

[Moreland, Kenneth]

It does not surprise me that D3 helped.  Many codes, Alegra and pretty much anything that writes Exodus files included, drops the connectivity information between processes when writing files.  D3 recovers that information.

Is running cell2point really necessary?  It shouldn't be.  This filter does an averaging of the field values at each point, which results in loss of the high frequency information.  If there is a problem with data between process data, cell2point could simply be hiding it with this averaging.

Granted, showing cell data often looks "blocky," and that should be OK.  However, if you notice a discontinuity that you can trace around the simulation process boundaries, that might be cause for concern.  It could be that the simulation is artificially introducing artifacts on the process boundaries, which in turn can skew all the results of the simulation.

-Ken


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>
>




   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090501/ed28c22f/attachment.htm>