I believe Mostyn's error is due to a change in PGI 8.0-x from earlier
releases (PGI has been known to do these kind of things). My point was
only that PGI is a tad different from our other compilers, and that we
do typically see kernel-related issues as well. So one needs to watch
out for P
On Mar 12, 2009, at 11:17 PM, Ralph Castain wrote:
I believe I reported this before on a different mailing list, but will
repeat it here. The PGI compilers rely on the Linux kernel for some
things. We found that the ability of the PGI compilers to build OMPI,
therefore, was highly dependent upon
I believe I reported this before on a different mailing list, but will
repeat it here. The PGI compilers rely on the Linux kernel for some
things. We found that the ability of the PGI compilers to build OMPI,
therefore, was highly dependent upon the specific Linux kernel on the
machine.
F
It's odd because PGI 7.0 and 7.1 compile OMPI just fine (don't know
about PGI 7.2).
On Mar 12, 2009, at 7:09 PM, Mark Potts wrote:
All,
I don't know PGI's compilers, but is it possible that since
"restrict"
was supposedly introduced as a C99 feature that it is not
supported
All,
I don't know PGI's compilers, but is it possible that since "restrict"
was supposedly introduced as a C99 feature that it is not supported
by default by their C compiler? This would explain the wording of
the error message which indicates interpretation of "restrict" as a
vari
Mostyn -- can you try this and see if it works with the PGI 8.0
compiler?
On Mar 12, 2009, at 6:20 PM, George Bosilca wrote:
Apparently, the PGI compiler (version 8) doesn't recognize restrict as
a keyword in a function prototype if the associated argument is not
named. There is one obvious
Apparently, the PGI compiler (version 8) doesn't recognize restrict as
a keyword in a function prototype if the associated argument is not
named. There is one obvious solution: remove the restrict keyword but
I don't think it's the right one.
Can you try to replace
typedef void (*ompi_op_b
Hi Amos,
It looks like you do not have permission to make the directory /usr/
local/etc. Either you need to run the make all install as root, so
you have permission to that directory, or you need to use the --
prefix= option to configure so that the installation gets
installed into a path
Hello Forum,
Attached is a file of my installation and trying examples
for openmpi-1.2.9 which were not successful. Hopefully the problem is
a simple one and obvious to a more experienced user.
I am trying to install and test openmpi-1.2.9. I found that I
could not use the Intel 11.0
Hello all.
I'm using openmpi-1.3 in this example, linux, gcc-4.3.2, configured
with nothing special.
If I run the following simple C code under valgrind, single process, I
get some errors about reading and writing already-freed memory:
---
#include
#include
int delete_
I should add that the problem disappears if I add a line
MPI::COMM_WORLD.Barrier ()
just before the loop which frees the intercommunicators.
I should not need to do this, right?
On Thu, Mar 12, 2009 at 4:57 PM, Mikael Djurfeldt wrote:
> Dear list,
>
> I get "Connection reset by peer" in Fina
Dear list,
I get "Connection reset by peer" in Finalize (see log below), but
*only* if I free my intercommunicators:
...
for (std::vector::iterator connector = connectors.begin ();
connector != connectors.end ();
++connector)
(*connector)->freeIntercomm ();
MP
Hi Sangamesh,
I'd look into making sure that the node you are using is not running
anything in parallel.
Make sure you allocate a whole node and it is clean from previous jobs.
Best,
INK
Hello INK,
I've run couple of jobs with different mpirun options.
CRITERIA 1:
On one of the nodes - connected to infiniband network:
Job No 1:
mpirun command: /opt/mpi/openmpi/1.3/intel/bin/mpirun --mca btl
^openib -np $NSLOTS -hostfile $TMPDIR/machines
/opt/apps/cpmd/3.11/ompi-atl
as/SOUR
14 matches
Mail list logo
