<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText"><span style="font-family:"Courier New"">David, et al,<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">I need some advice on pipeline re-execution.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">I've removed all the spurious pipeline re-execution problems I had, by simply stopping the NeedToExecute in the executives from ever saying yes based on ghost cells. However, I can't do the same
for number of pieces.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">I suspect that one reason my filters are crashing on massive data and causing issues on others is because paraview constantly triggers unnecessary executions when stuff hasn't changed.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">My pipeline is essentially as follows (please view using wide window and courier font)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">H5PartReader (reads N pieces, exports polydata)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""> |<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""> V<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">ParticleRepartitionFilter (UG/polydata, redistributes particles across processes<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">and replaces ExtentTranslator with BoundsExtentTranslator, redistribution<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">is spatial (KdTree) and irregular – also adds scalar array to
<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">denote ghost particles which are duplicated around process boundaries)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""> |<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New""> |___________________<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">___ V<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">| ImageGridSampler (creates a vtkImageData grid and uses the<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">| BoundsExtentTranslator to get the right extents for the piece<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">| this means we can get irregular subdivisions of space)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">| ________________|<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">V V<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">SPHResampler (any datatype, resamples the particles using an SPH kernel onto<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">the vtkImageData provided by the image sampler – the use of the BoundsExtentTranslator<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">in the earlier stages ensures we have the data we want to reample on the right process<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-family:"Courier New"">for the sampling geometry)<o:p></o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This bit works fine (on the desktop, but sometimes crashes on the cluster when running N=64 processes), ... but prompted by your suggestion, I threw in a volume renderer after the SPHResampler to view the resampled data as a volume.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This triggers a whole bunch of filter reexecutions, caused by updateNumberOfPieces(1) != dataNumberOfPieces(4) (4 being what I’d expect it to be not 1 which is just silly)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I have not yet identified who is setting the update pieces to 1, when all the rest of the pipeline is using 4, but I experimented with using wavelet sources and creating pipelines which were similar and I found that the problem was not
unique to my setup.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I’d like to know if there is any rule to<o:p></o:p></p>
<p class="MsoPlainText">NOT SET Maximum_number_of_pieces<o:p></o:p></p>
<p class="MsoPlainText">NOT SET Any kind of piece information<o:p></o:p></p>
<p class="MsoPlainText">YES SET Extent information etc<o:p></o:p></p>
<p class="MsoPlainText">in particular kinds of filters.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">By which I mean, image data generators should NEVER set maximum number of pieces? and piece extent translators etc etc. I’m looking for clues as to why my pipeline might misbehave, because debugging the executives is hard work and time
consuming (particularly so since David completely buggered them up with all his fancy streaming stuff
<span style="font-family:Wingdings">J</span> )<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Any advice welcome.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">JB<o:p></o:p></p>
<p class="MsoPlainText">PS. I see that paraview has updated it’s number scheme to 3.12 RCxxx : noting that Paraview only really works properly in serial, is this wise?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><span lang="EN-US">-----Original Message-----<br>
From: paraview-developers-bounces@paraview.org [mailto:paraview-developers-bounces@paraview.org] On Behalf Of Biddiscombe, John A.<br>
Sent: 07 September 2011 09:57<br>
To: David E DeMarle<br>
Cc: paraview-developers@paraview.org<br>
Subject: Re: [Paraview-developers] suspicious behaviour with structured Grids (in partuicular)</span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">David<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">>Was volume rendering involved?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Not involved. The visual errors appear when drawing just a surface representation.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I tried a large run on a 64 pvserver job yesterday using the new imagedata version of the resampler, after the resampling completed, pvservers shut down as before and I lost connection. I am trying to debug it on the cluster today but
my parallel debugging skills on linux are sadly quite poor.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">JB<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">David E DeMarle<o:p></o:p></p>
<p class="MsoPlainText">Kitware, Inc.<o:p></o:p></p>
<p class="MsoPlainText">R&D Engineer<o:p></o:p></p>
<p class="MsoPlainText">21 Corporate Drive<o:p></o:p></p>
<p class="MsoPlainText">Clifton Park, NY 12065-8662<o:p></o:p></p>
<p class="MsoPlainText">Phone: 518-881-4909<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On Thu, Sep 1, 2011 at 2:32 AM, Biddiscombe, John A. <biddisco@cscs.ch> wrote:<o:p></o:p></p>
<p class="MsoPlainText">> I've had a lot of problems with a particular set of filters of mine which resample SPH data onto grids.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> I have a Grid Generator class which is used as the sample location. This class outputs a vtkStructuredGrid.<o:p></o:p></p>
<p class="MsoPlainText">> When running in Parallel, I see very odd behaviour - which appears similar to a post I saw some months ago but can't find now, where the data displayed appears to be incorrect. Almsot as though the data from process 0 is being drawn
on all processes and something is just not right, but I can't quite pin it down.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> Because I have custom extent translators, dodgy extent manipulations and all parallel features, I can never be quite sure that it's paraview that's fundamentally broken or my stuff.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> However, in the case where the resampling grid is regular and axis aligned, the output could be vtkImageData, which I believe does work quite well in parallel, so I made a new stripped down resampler which outputs only image data.
This works fine. The extent translation/manipulation is the same, the resampling the same, everything the same, except it produces image data.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> This one doesn't crash or misbehave when run in parallel, however the image looks wrong 'first time' it is done, if I delete the filter, recreate a second one and then reexecute using identical settings, I get a completely different
image and it looks perfect.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> I really don't understand what is going on, but my feeling now is that paraview is broken somewhere deep inside (and is essentially unfit for purpose)<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> The problem is slightly less bad on 3.11 than on 3.10, but I still don't know what is actually wrong. I still don't know if I've messed up, or if ParaView is messing me up. (I have a complicated scenario where a multi-input filter
passes update extent information from the second input).<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> I'm only posting this because I have some vague memory that someone else reported duplicated colours from process 0 on some gridded data in parallel and it's just possible, I'm seeing aspects of the same bug. I can't file a proper
bug report because I'm still not completely sure a bug really exists. I'm just hoping someone reading this might mention something which triggers other thoughts, comments etc.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> yours<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> JB<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> --<o:p></o:p></p>
<p class="MsoPlainText">> John Biddiscombe, email:biddisco @ cscs.ch<o:p></o:p></p>
<p class="MsoPlainText">> http://www.cscs.ch/<o:p></o:p></p>
<p class="MsoPlainText">> CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07<o:p></o:p></p>
<p class="MsoPlainText">> Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">> Paraview-developers mailing list<o:p></o:p></p>
<p class="MsoPlainText">> Paraview-developers@paraview.org<o:p></o:p></p>
<p class="MsoPlainText">> http://public.kitware.com/mailman/listinfo/paraview-developers<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">Paraview-developers mailing list<o:p></o:p></p>
<p class="MsoPlainText">Paraview-developers@paraview.org<o:p></o:p></p>
<p class="MsoPlainText">http://public.kitware.com/mailman/listinfo/paraview-developers<o:p></o:p></p>
</div>
</body>
</html>