<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
attached an example of how we configure the environment and launch
pvbatch on nautilus sgi uv 1000. <br>
<br>
On 08/09/2012 09:20 AM, Burlen Loring wrote:
<blockquote cite="mid:5023E34F.5080805@lbl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
this sounds more and more external to pv. For example if you
compiled your program with one version of mpi but tried to run it
with another, you'd very likely see exactly what you are seeing
here. A few of things you could look at to boost your confidence:
"module list", "which mpirun", "echo $LD_LIBRARY_PATH", "ldd
pvbatch" all of which will let you confirm that your environment
is using the mpi and library versions that you expect, and that PV
itself can find it's dependencies.<br>
<br>
Sometimes sys admins in attempt to make things easy load modules
for you. So when you are put into a new shell you environment is
changed. And of course the default modules will change as packages
are updated. This could lead to unexepected weird problems over
time. So, when running something like paraview that has a lot of
dependencies, it can be helpful if you "freeze" your PATH and
LD_LIBRARY_PATH. copy these into a bash script (or module file)
which you source when using paraview, and then pass these into
your qsub script with "-v" option.<br>
<br>
On 08/09/2012 07:47 AM, Ganesh Vijayakumar wrote:
<blockquote
cite="mid:CAFtK+esJzQUECBq53kzgt2tTfXo06fCaKpC_97OWKyiwXNtyFw@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Wed, Aug 8, 2012 at 5:25 PM, Burlen
Loring <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> assuming that you've
already examined all the output, and there's no other
info, you could do a couple of things: put some print
statements in your python script to see how far it makes
it. Also you could use MPT specific environment variables
that tell mpt to print a stack trace, see man mpi. A debug
build may be helpful for this.<br>
<br>
before all this debugging effort you may want try a very
simple script to gain confidence that things are indeed
working correctly with your build. I'll send a simple test
script that might be of use for that. <br>
<div>
<div class="h5"> <br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It doesn't even get past the first line i.e the module
import line. I'm unable to get it to force a core dump as
"ulimit -c unlimited" is not working. I've asked the system
administrator about the issue. </div>
<div><br>
</div>
<div>But in the meanwhile can I force a debug compilation? How
can I do that? Just add "-g" to CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS?</div>
<div><br>
</div>
<div>ganesh</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>