<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
span.EmailStyle17
        {font-family:"Calibri","sans-serif";
        color:windowtext}
.MsoChpDefault
        {font-family:"Calibri","sans-serif"}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
-->
</style><style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" lang="EN-US" link="blue" vlink="purple">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Just some follow-up information I hope to shed some light on this problem. I used pdb to debug pvserver running with mpirun on the server and found this floating point exception
 error happens on the line below:<br>
<br>
Program received signal SIGFPE, Arithmetic exception.<br>
0x00002ad33e95021b in vtkViewport::DisplayToView (this=0x43a2670)<br>
&nbsp;&nbsp;&nbsp; at /home/hyi2/Download/ParaView-3.14.1-Source/VTK/Filtering/vtkViewport.cxx:204<br>
204&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (sizex*(this-&gt;Viewport[2]-this-&gt;Viewport[0])) - 1.0;<br>
<br>
which puzzles me since I cannot imagine why this could cause floating point exception (I cannot see possibility of &quot;divide by zero&quot; or other possible arithmetic exception). I did try to check or uncheck &quot;Remote Render Threshold&quot; checkbox both ways which results
 in the same failure in the same statement as noted above. Also, isocontouring filter runs fine with correct visual output, but slicing and clipping filters result in same errors as noted above.<br>
<br>
Hope this additional debug info could shed some light and trigger some idea on what could be the problem. Perhaps there is a possibility it is NVidia driver related? But in my configuration, HPC server uses MESA software rendering and my client NVidia driver
 is up to date with Geforce GTX580 graphics card. <br>
<br>
Thanks for any ideas on what could cause this problem!<br>
<br>
Hong <br>
<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF39872"><font color="#000000" face="Tahoma" size="2"><b>From:</b> paraview-bounces@paraview.org [paraview-bounces@paraview.org] on behalf of Hong Yi [hongyi@renci.org]<br>
<b>Sent:</b> Friday, February 22, 2013 12:27 PM<br>
<b>To:</b> paraview@paraview.org<br>
<b>Subject:</b> [Paraview] floating point exception error when doing slice filter (only happen when running pvserver remotely in parallel)<br>
</font><br>
</div>
<div></div>
<div>
<div class="WordSection1">
<p class="MsoNormal">I built ParaView server with MPI on a HPC cluster with OSMesa support since the cluster does not have graphics hardware. The MPI compiler used to build ParaView is mpich2/gnu412x64/1.4-shared. Paraview server built successfully on the cluster
 without any error. I can successfully connect to the pvserver running on multiple nodes remotely via Paraview client running on my local desktop, load data in, and do gradient and vorticity computation, and look at isosurfaces without problems. However, when
 I do slice filter to look at one slice, as soon as I click on slice filter, pvserver aborts with floating point exception error. It is not the data problem because I can do slice filter without problem for the same data if I run builtin Paraview server/client
 locally, so the problem only occurs when the local client connects to pvserver running remotely on multiple nodes (or on one node) via mpirun. So far, the slice filter is the only filter I have run into with this floating point exception error raised by the
 remote pvserver. The other filters such as gradient of unstructured data, calculator of vorticity, isocontour all run successfully with correct results produced. Any idea on what could cause this problem is very much appreciated!</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Thanks,</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Hong</p>
</div>
</div>
</div>
</div>
</body>
</html>