<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Apparently I needed to register for the list before sending out this message according to someone I know...anyway, here it is.<br><br>Sohail<br><br><br>--- On <b>Thu, 8/5/10, Sohail Shafii <i><sohailshafii@yahoo.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Sohail Shafii <sohailshafii@yahoo.com><br>Subject: vtk grids and parallelization<br>To: paraview-developers@paraview.org<br>Date: Thursday, August 5, 2010, 10:27 AM<br><br><div id="yiv1294106316"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font: inherit;" valign="top"><pre>Hi,<br><br>I have been able to split a vector data set across two instances <br>of my custom filter. I noticed that the data set's extent <br>(or size) that each filter (on each processor) sees is split <br>up from
the original. This data is stored in a vtkStructuredGrid...<br><br>Normally this isn't a problem. In my case, however, I need to <br>convert from the tuple point id (which is a 1D analogue of a <br>three-dimensional index) to a 3D point in the data set. I'm <br>writing an algorithm that starts from a point in the data set <br>and moves in 3D space, so I need the X, Y, Z coordinates of the<br> point in the data set. Also, I need to calculate the <br>interpolated value of points that lie somewhere in the grid, <br>which again falls back on the need for three dimensions.<br><br>So the reason this is a problem is because each filter is<br> <br>attempting to do this 1D -> 3D conversion and doing so requires <br>the full extent of the grid (basically the size of the data). <br>Since the extent is split up when the filter is parallelized, <br>things screw up. Is there a way to store the full extent of <br>the original (structured grid) data set
before parallelization?<br><br>Thanks, Sohail<br></pre></td></tr></tbody></table><br>
</div></blockquote></td></tr></table><br>