<HTML>
<HEAD>
<TITLE>Re: [Paraview] Exodus weirdness</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Actually, I don’t think you should have to run CleanToGrid at all. D3 should be merging all coincident points, both locally and globally. The one exception is if the global ids in the Exodus file is wrong. If you think that might be an issue, try turning off the global ids in the Exodus reader.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 5/4/09 9:23 AM, "Brian Wylie" <<a href="bnwylie@sandia.gov">bnwylie@sandia.gov</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Also, just a quick observation...<BR>
<BR>
<BR>
CleanToGrid = Intraprocessor clean up of coincident node points<BR>
D3 = Interprocessor clean up of coincident node points (through the use of ghost cells).<BR>
<BR>
<BR>
So I think (I might be corrected) the correct order to do these is CleanToGrid first and then D3. D3 will then have less data to hoist around (by it's nature D3 is a more heavyweight process so any data reduction you can do is good).<BR>
<BR>
<BR>
Brian Wylie - Org 1424<BR>
Sandia National Laboratories<BR>
MS 1323 - Building CSRI/242<BR>
(505)844-2238 FAX(505)284-2518 <BR>
_______ __<BR>
/_ __(_) /_____ _____<BR>
/ / / / __/ __ `/ __ \<BR>
/ / / / /_/ /_/ / / / /<BR>
/_/ /_/\__/\__,_/_/ /_/<BR>
Informatics Toolkit<BR>
<BR>
-----Original Message-----<BR>
From: <a href="paraview-bounces@paraview.org">paraview-bounces@paraview.org</a> [<a href="mailto:paraview-bounces@paraview.org">mailto:paraview-bounces@paraview.org</a>] On Behalf Of Rick Angelini<BR>
Sent: Friday, May 01, 2009 9:09 AM<BR>
To: Weirs, V Gregory<BR>
Cc: alegra-help; <a href="paraview@paraview.org">paraview@paraview.org</a><BR>
Subject: Re: [Paraview] Exodus weirdness<BR>
<BR>
I will re-investigate the data to determine if D3 and then CleanToGrid does the trick.<BR>
<BR>
Weirs, V Gregory wrote:<BR>
><BR>
> OK, without D3 you will always see the processor boundaries. Paraview<BR>
> is see all the individual .exo files as independent, until you apply<BR>
> D3. CleanToGrid takes points that are essentially on top of each other<BR>
> and merges them. Nodes on processor boundaries are written to both<BR>
> exodus files, so before CleanToGrid you have, effectively, double<BR>
> valued nodes at processor boundaries; even though the nodes are at the<BR>
> same location, and the values are actually the same (if we wrote them<BR>
> out correctly) Paraview is probably trying to interpolate between them<BR>
> somehow.<BR>
><BR>
> CellToPoint can hide the discrepancy by slightly smoothing the data<BR>
> when interpolating from cells to points.<BR>
><BR>
> These are possible and sensible explanations, but without seeing the<BR>
> data we can't be sure. Try D3 and CleanToGrid, and if you can still<BR>
> see processor boundaries we would want to look deeper, if that's possible.<BR>
><BR>
> Greg<BR>
><BR>
> On 5/1/09 8:27 AM, "Rick Angelini" <<a href="angel@arl.army.mil">angel@arl.army.mil</a>> wrote:<BR>
><BR>
> It's the boundaries from the original simulation. However, running<BR>
> through the D3 filter and then doing a cell2point seems to clean<BR>
> up the<BR>
> boundary edges.<BR>
><BR>
> Thanks<BR>
><BR>
><BR>
> Moreland, Kenneth wrote:<BR>
> > I don't recall seeing anything quite like that before. Are these<BR>
> > boundaries in question those in the original simulation (noted by the<BR>
> > file number) or the processes in your visualization (which can be<BR>
> > annotated with the Process Id Scalars filter)? Does running the data<BR>
> > through D3 help?<BR>
> ><BR>
> > -Ken<BR>
> ><BR>
> ><BR>
> > On 4/30/09 1:30 PM, "Rick Angelini" <<a href="angel@arl.army.mil">angel@arl.army.mil</a>> wrote:<BR>
> ><BR>
> > I am working with one of my customers viewing an Exodus dataset<BR>
> > generated by Alegra(?) using 256p. The dataset loads fine, but seems<BR>
> > to have an issue at the processor boundaries. When viewing the<BR>
> > dataset using something like a clip plane or isosurface, the data<BR>
> > seems<BR>
> > to be "slipped" (or offset) at each processor boundary - that is,<BR>
> > there<BR>
> > appears to be a hard edge at each processor boundary. Unfortunately,<BR>
> > I'm not able to post an image that represents the problem.<BR>
> ><BR>
> > I'm not familiar with the Exodus data format, but it looks like it<BR>
> > could<BR>
> > be an issue associate with ghost cells. Either there are no ghost<BR>
> > cells at the processor boundary layer, or they're possibly being<BR>
> > mismanaged? Curiously enough, this is the first time we've noticed<BR>
> > this problem after processing quite a few Exodus datasets. We're<BR>
> > using the latest production version of Paraview (3.4) and we've also<BR>
> > been able to duplicate the issue with other visualization tools,<BR>
> so we<BR>
> > think this is a problem with this particular Exodus dataset, if<BR>
> > not the<BR>
> > Exodus format in general.<BR>
> ><BR>
> > Any ideas?<BR>
> ><BR>
> ><BR>
> > _______________________________________________<BR>
> > Powered by www.kitware.com<BR>
> ><BR>
> > Visit other Kitware open-source projects at<BR>
> > <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
> ><BR>
> > Please keep messages on-topic and check the ParaView Wiki at:<BR>
> > <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
> ><BR>
> > Follow this link to subscribe/unsubscribe:<BR>
> > <a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
> ><BR>
> ><BR>
> ><BR>
> ><BR>
> > **** Kenneth Moreland<BR>
> > *** Sandia National Laboratories<BR>
> > ***********<BR>
> > *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
> > ** *** ** phone: (505) 844-8919<BR>
> > *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
> <<a href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/%7Ekmorel</a>> <<a href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/%7Ekmorel</a>><BR>
> ><BR>
> _______________________________________________<BR>
> Powered by www.kitware.com<BR>
><BR>
> Visit other Kitware open-source projects at<BR>
> <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
><BR>
> Please keep messages on-topic and check the ParaView Wiki at:<BR>
> <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
><BR>
> Follow this link to subscribe/unsubscribe:<BR>
> <a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
><BR>
><BR>
_______________________________________________<BR>
Powered by www.kitware.com<BR>
<BR>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
<BR>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
<BR>
Follow this link to subscribe/unsubscribe:<BR>
<a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
<BR>
<BR>
_______________________________________________<BR>
Powered by www.kitware.com<BR>
<BR>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
<BR>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
<BR>
Follow this link to subscribe/unsubscribe:<BR>
<a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><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>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** *** ** phone: (505) 844-8919<BR>
*** web: <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>