Thanks Kevin, that clarifies it a lot. <div><br></div><div>- Wes<br><br><div class="gmail_quote">On Mon, Oct 26, 2009 at 3:47 PM, Kevin H. Hobbs <span dir="ltr"><<a href="mailto:hobbsk@ohiou.edu">hobbsk@ohiou.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, 2009-10-26 at 15:15 -0400, Wes Turner wrote:<br>
> Just for clarification. When I read the initial post, my assumption<br>
> was that the difference between the parallel and serial results was<br>
> due to a different ordering of operations and was not necessarily a<br>
> "real" error. I.e. while the serial and parallel results could be<br>
> different, they could both be equally valid. Is this the case, or is<br>
> it in fact a true failure in the parallel implementation?<br>
><br>
><br>
> - Wes<br>
<br>
</div>I have to call it real error because it's big, I don't know what's<br>
causing it, and I can't make it go away.<br>
<br>
Having said that I don't care about it very much because :<br>
<br>
I'm trying to do fast marching in parallel.<br>
<br>
The error shows up in background pixels near the piece boundaries.<br>
<br>
I'm interested in the pixels in the dendrites with values less than a<br>
few hundred, so differences of thousands in the background where values<br>
are stratospheric don't concern me. ( that was a mouthful )<br>
<br>
I can't say that somebody else won't care though. ( image compare sure<br>
freaks out )<br>
</blockquote></div><br><br clear="all"><br>-- <br>Wesley D. Turner, Ph.D.<br>Kitware, Inc.<br>Technical Leader<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-881-4920<br>
</div>