<HTML>
<HEAD>
<TITLE>Re: [Paraview] Exodus weirdness</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>It does not surprise me that D3 helped. &nbsp;Many codes, Alegra and pretty much anything that writes Exodus files included, drops the connectivity information between processes when writing files. &nbsp;D3 recovers that information.<BR>
<BR>
Is running cell2point really necessary? &nbsp;It shouldn&#8217;t be. &nbsp;This filter does an averaging of the field values at each point, which results in loss of the high frequency information. &nbsp;If there is a problem with data between process data, cell2point could simply be hiding it with this averaging.<BR>
<BR>
Granted, showing cell data often looks &#8220;blocky,&#8221; and that should be OK. &nbsp;However, if you notice a discontinuity that you can trace around the simulation process boundaries, that might be cause for concern. &nbsp;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.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 5/1/09 8:27 AM, &quot;Rick Angelini&quot; &lt;<a href="angel@arl.army.mil">angel@arl.army.mil</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>It's the boundaries from the original simulation. However, running<BR>
through the D3 filter and then doing a cell2point seems to clean up the<BR>
boundary edges.<BR>
<BR>
Thanks<BR>
<BR>
<BR>
Moreland, Kenneth wrote:<BR>
&gt; I don&#8217;t recall seeing anything quite like that before. Are these<BR>
&gt; boundaries in question those in the original simulation (noted by the<BR>
&gt; file number) or the processes in your visualization (which can be<BR>
&gt; annotated with the Process Id Scalars filter)? Does running the data<BR>
&gt; through D3 help?<BR>
&gt;<BR>
&gt; -Ken<BR>
&gt;<BR>
&gt;<BR>
&gt; On 4/30/09 1:30 PM, &quot;Rick Angelini&quot; &lt;<a href="angel@arl.army.mil">angel@arl.army.mil</a>&gt; wrote:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;I am working with one of my customers viewing an Exodus dataset<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;generated by Alegra(?) using 256p. The dataset loads fine, but seems<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;to have an issue at the processor boundaries. When viewing the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;dataset using something like a clip plane or isosurface, the data<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;seems<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;to be &quot;slipped&quot; (or offset) at each processor boundary - that is,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;there<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;appears to be a hard edge at each processor boundary. Unfortunately,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;I'm not able to post an image that represents the problem.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;I'm not familiar with the Exodus data format, but it looks like it<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;could<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;be an issue associate with ghost cells. Either there are no ghost<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;cells at the processor boundary layer, or they're possibly being<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;mismanaged? Curiously enough, this is the first time we've noticed<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;this problem after processing quite a few Exodus datasets. We're<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;using the latest production version of Paraview (3.4) and we've also<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;been able to duplicate the issue with other visualization tools, so we<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;think this is a problem with this particular Exodus dataset, if<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;not the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Exodus format in general.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Any ideas?<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;_______________________________________________<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Powered by www.kitware.com<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Visit other Kitware open-source projects at<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Please keep messages on-topic and check the ParaView Wiki at:<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Follow this link to subscribe/unsubscribe:<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; **** Kenneth Moreland<BR>
&gt; *** Sandia National Laboratories<BR>
&gt; ***********<BR>
&gt; *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
&gt; ** *** ** phone: (505) 844-8919<BR>
&gt; *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a> &lt;<a href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/%7Ekmorel</a>&gt;<BR>
&gt;<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'><BR>
&nbsp;&nbsp;&nbsp;**** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Kenneth Moreland<BR>
&nbsp;&nbsp;&nbsp;&nbsp;*** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sandia National Laboratories<BR>
*********** &nbsp;<BR>
*** *** *** &nbsp;email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** &nbsp;*** &nbsp;** &nbsp;phone: (505) 844-8919<BR>
&nbsp;&nbsp;&nbsp;&nbsp;*** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;web: &nbsp;&nbsp;<a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>