Yeah, just wanted to make sure you were seeing the same mpiexec in both cases.
There shouldn't be any issue with providing the complete path, though I can
take a look
On Sep 17, 2014, at 4:29 PM, Nico Schlömer wrote:
>> You should check that your path would also hit /usr/bin/mpiexec and not s
> You should check that your path would also hit /usr/bin/mpiexec and not some
> other version of it
```
$ which mpiexec
/usr/bin/mpiexec
```
Is this what you mean?
–Nico
On Thu, Sep 18, 2014 at 1:04 AM, Ralph Castain wrote:
> You should check that your path would also hit /usr/bin/mpiexec and
You should check that your path would also hit /usr/bin/mpiexec and not some
other version of it
On Sep 17, 2014, at 4:01 PM, Nico Schlömer wrote:
> Hi all!
>
> Today, I observed a really funky behavior of my stock
> ```
> $ mpiexec --version
> mpiexec (OpenRTE) 1.6.5
>
> Report bugs to http:
Hi all!
Today, I observed a really funky behavior of my stock
```
$ mpiexec --version
mpiexec (OpenRTE) 1.6.5
Report bugs to http://www.open-mpi.org/community/help/
```
on Ubuntu 14.04. When running one of my test codes with
```
$ mpiexec -n 2 ioTest
[...]
```
all is fine. If instead I use the fu
Hi Rob,
As you pointed out in April that there are many cases that could arouse
ADIOI_Set_lock error. My code writes to a file at a location specified by a
shared file pointer (it is a blocking and collective call):
MPI_File_write_ordered(contactFile, const_cast (inf.str().c_str()),
length, MP
