Hi all,
(Sorry, I have sent this to "users" but I should have sent it to "devel"
list instead. Sorry for the mess...)
I have attached a very small example which raise an assertion.
The problem is arising from a process which does not have any element to
write in a file (and then in the MPI_
Hi,
I have sent a previous message showing something that I think is a bug
(or maybe a misuse, but...).
I worked on the example sent to have it simplified: now it is almost
half of the lines of code and the structures are more simple... but
still showing the wrong behaviour.
Briefly, we co
Sorry,
here is the attachment...
Eric
On 04/23/2013 09:54 AM, Eric Chamberland wrote:
Hi,
I have sent a previous message showing something that I think is a bug
(or maybe a misuse, but...).
I worked on the example sent to have it simplified: now it is almost
half of the lines of code and
another information: I just tested the example with Intel MPI 4.0.1.007
and it works correctly...
So the problem seems to be only with OpenMPI... which is the default
distribution we use... :-/
Is my example code too long?
Eric
Le 2013-04-23 09:55, Eric Chamberland a écrit :
Sorry,
here
the datatypes to be relative to each
instance's *this* pointer.
Doing so allows MPI to read/write the data relative to the specific instance of
the objects that you're trying to send/receive.
Make sense?
On Apr 23, 2013, at 5:01 PM, Eric Chamberland
wrote:
another information:
April 9 George commited a fix for the bug reported
by Thomas Jahns:
http://www.open-mpi.org/community/lists/devel/2013/04/12268.php
-Paul
On Tue, Apr 23, 2013 at 5:35 PM, Eric Chamberland
<mailto:eric.chamberl...@giref.ulaval.ca>> wrote:
Hi Jeff,
thanks for your answer!
Hi,
I am testing for the first time the 2.X release candidate.
I have a segmentation violation using MPI_File_write_all_end(MPI_File
fh, const void *buf, MPI_Status *status)
The "special" thing, may be that in the faulty test cases, there are
processes that haven't written anything, so they
convenient for you...
Thanks!
Eric
Thanks
Edgar
On 7/8/2016 11:32 AM, Eric Chamberland wrote:
Hi,
I am testing for the first time the 2.X release candidate.
I have a segmentation violation using MPI_File_write_all_end(MPI_File
fh, const void *buf, MPI_Status *status)
The "special&q
On 08/07/16 01:44 PM, Edgar Gabriel wrote:
ok, but just to be able to construct a test case, basically what you are
doing is
MPI_File_write_all_begin (fh, NULL, 0, some datatype);
MPI_File_write_all_end (fh, NULL, &status),
is this correct?
Yes, but with 2 processes:
rank 0 writes somethi
.
Thanks!
Edgar
On 7/8/2016 1:14 PM, Eric Chamberland wrote:
On 08/07/16 01:44 PM, Edgar Gabriel wrote:
ok, but just to be able to construct a test case, basically what you are
doing is
MPI_File_write_all_begin (fh, NULL, 0, some datatype);
MPI_File_write_all_end (fh, NULL, &status),
is
und a new RC if something
drastic
appeared. We want to fix this issue (and it will be fixed), but we've
decided to
defer the fix for this issue to a 2.0.1 bug fix release.
Howard
2016-07-12 13:51 GMT-06:00 Eric Chamberland
mailto:eric.chamberl...@giref.ulaval.ca>>:
Hi Edgard,
Hi,
FYI: I've tested the SHA e28951e
From git clone launched around 01h19:
http://www.giref.ulaval.ca/~cmpgiref/dernier_ompi/2016.07.13.01h19m30s_config.log
Eric
On 13/07/16 04:01 PM, Pritchard Jr., Howard wrote:
Jeff,
I think this was fixed in PR 1227 on v2.x
Howard
-diff.githubusercontent.com/raw/open-mpi/ompi-release/pull/1263.patch
Ok but I think it is already included into the master of the clone I
get... :)
Cheers,
Eric
Cheers,
Gilles
On 7/14/2016 3:37 AM, Eric Chamberland wrote:
Hi Howard,
ok, I will wait for 2.0.1rcX... ;)
I've put in pl
ul 13, 2016, at 3:01 PM, Ralph Castain wrote:
Hmmm…I see where the singleton on master might be broken - will check later
today
On Jul 13, 2016, at 11:37 AM, Eric Chamberland
wrote:
Hi Howard,
ok, I will wait for 2.0.1rcX... ;)
I've put in place a script to download/compile OpenMPI+PETSc(
Edgar
On 7/12/2016 2:51 PM, Eric Chamberland wrote:
Hi Edgard,
I just saw that your patch got into ompi/master... any chances it goes
into ompi-release/v2.x before rc5?
thanks,
Eric
On 08/07/16 03:14 PM, Edgar Gabriel wrote:
I think I found the problem, I filed a pr towards master, and if that
Hi,
has someone tried OpenMPI 2.0 with Petsc 3.7.2?
I am having some errors with petsc, maybe someone have them too?
Here are the configure logs for PETSc:
http://www.giref.ulaval.ca/~cmpgiref/dernier_ompi/2016.07.25.01h16m02s_configure.log
http://www.giref.ulaval.ca/~cmpgiref/dernier_ompi/20
, should I ever modify these VecScatterCreate options?
How do they change the performances of the code on large problems?
Thanks,
Eric
On 25/07/16 02:57 PM, Matthew Knepley wrote:
On Mon, Jul 25, 2016 at 11:33 AM, Eric Chamberland
mailto:eric.chamberl...@giref.ulaval.ca>> wrote:
Hi,
875
Thanks,
Eric
Cheers,
Gilles
On 7/26/2016 3:33 AM, Eric Chamberland wrote:
Hi,
has someone tried OpenMPI 2.0 with Petsc 3.7.2?
I am having some errors with petsc, maybe someone have them too?
Here are the configure logs for PETSc:
http://www.giref.ulaval.ca/~cmpgiref/dernier_ompi/201
Hi,
It is the third time this happened into the last 10 days.
While running nighlty tests (~2200), we have one or two tests that fails
at the very beginning with this strange error:
[lorien:142766] [[9325,5754],0] usock_peer_recv_connect_ack: received
unexpected process identifier [[9325,0],
Other relevant info: I never saw this problem with OpenMPI 1.6.5,1.8.4
and 1.10.[3,4] which runs the same test suite...
thanks,
Eric
On 13/09/16 11:35 AM, Eric Chamberland wrote:
Hi,
It is the third time this happened into the last 10 days.
While running nighlty tests (~2200), we have one
On 13/09/16 12:11 PM, Pritchard Jr., Howard wrote:
Hello Eric,
Is the failure seen with the same two tests? Or is it random
which tests fail? If its not random, would you be able to post
No, the tests that failed were different ones...
the tests to the list?
Also, if possible, it would
ase_verbose=5 to all tests and wait until it hangs?
Thanks!
Eric
Cheers,
Gilles
On 9/14/2016 12:35 AM, Eric Chamberland wrote:
Hi,
It is the third time this happened into the last 10 days.
While running nighlty tests (~2200), we have one or two tests that
fails at the very beginning with th
(unsigned long)jobfam));
configure Open MPI with --enable-debug and rebuild
and then
export OMPI_MCA_plm_base_verbose=4
and run your tests.
when the problem occurs, you will be able to check which pids
produced the faulty jobfam, and that could hint to a c
logs, so we might spot a conflict
ok, I will launch it manually later today, but it will be automatic
tonight (with export OMPI_MCA_plm_base_verbose=5).
Thanks!
Eric
Cheers,
Gilles
On Wednesday, September 14, 2016, Eric Chamberland
mailto:eric.chamberl...@giref.ulaval.ca>> wrote:
?
or a unique $TMP per "batch" of run ?
in the first case, my understanding is that conflicts cannot happen ...
once you hit the bug, can you please please post the output of the
failed a.out,
and run
egrep 'jobfam|stop'
on all your logs, so we might spot a conflict
Cheers
he process..
Thanks for all the support!
Eric
Cheers,
Gilles
On 9/15/2016 2:58 AM, Eric Chamberland wrote:
Ok,
one test segfaulted *but* I can't tell if it is the *same* bug because
there has been a segfault:
stderr:
http://www.giref.ulaval.ca/~cmpgir
or fix this too?
Thanks again!
Eric
On 15/09/16 09:32 AM, Eric Chamberland wrote:
Hi Gilles,
On 15/09/16 03:38 AM, Gilles Gouaillardet wrote:
Eric,
a bug has been identified, and a patch is available at
https://patch-diff.githubusercontent.com/raw/open-mpi/ompi-release/pull/1376.patch
the bug
y)
Cheers,
Gilles
On Friday, September 16, 2016, Eric Chamberland
mailto:eric.chamberl...@giref.ulaval.ca>> wrote:
Hi,
I know the pull request has not (yet) been merged, but here is a
somewhat "different" output from a single sequential test
(automatically) la
Hi,
since commit 18f23724a, our nightly base test is broken on v2.x branch.
Strangely, on branch v3.x, it broke the same day with 2fd9510b4b44, but
was repaired some days after (can't tell exactly, but at most it was
fixed with fa3d92981a).
I get segmentation faults or deadlocks in many case
ok, thanks a lot! :)
Eric
On 17/10/18 01:32 PM, Nathan Hjelm via devel wrote:
Ah yes, 18f23724a broke things so we had to fix the fix. Didn't apply it
to the v2.x branch. Will open a PR to bring it over.
-Nathan
On Oct 17, 2018, at 11:28 AM, Eric Chamberland
wrote:
Hi,
since c
On 12/11/2014 05:45 AM, Ralph Castain wrote:
...
by the reporters. Still, I would appreciate a fairly thorough testing as
this is expected to be the last 1.8 series release for some time.
Is is relevant to report valgrind leaks? Maybe they are "normal" or
not, I don't know. If they are norm
On 12/12/2014 11:38 AM, Jeff Squyres (jsquyres) wrote:
Did you configure OMPI with --enable-memchecker?
No, only "--prefix="
Eric
On 12/12/2014 01:12 PM, Ralph Castain wrote:
I just checked it with —enable-memchecker —with-valgrind and found that many of
these are legitimate leaks. We can take a look at them, though as I said,
perhaps may wait for 1.8.5 as I wouldn’t hold up 1.8.4 for it.
wait!
When end-developpers of
Hi,
I first saw this message using 1.8.4rc3:
--
WARNING: No loopback interface was found. This can cause problems
when we spawn processes as they are likely to be unable to connect
back to their host daemon. Sadly, it may ta
Forgot this:
ompi_info -all :
http://www.giref.ulaval.ca/~ericc/ompi_bug/ompi_info.all.184rc3.txt.gz
config.log: http://www.giref.ulaval.ca/~ericc/ompi_bug/config.184rc3.log.gz
Eric
Hi,
I encountered a new bug while testing our collective MPI I/O
functionnalities over NFS. This is not a big issue for us, but I think
someone should have a look at it.
While running at 3 processes, we have this error on rank #0 and rank #2,
knowing that rank #1 have nothing to write (0 le
please don't flame me... ;-) )
Anyway,
thanks,
Eric
On 12/19/2014 02:16 PM, Howard Pritchard wrote:
HI Eric,
Does your app also work with MPICH? The romio in Open MPI is getting a
bit old, so it would be useful to know if you see the same valgrind
error using a recent MPICH.
Howard
2014-12-
On 12/19/2014 09:52 PM, Rob Latham wrote:
Please don't use NFS for MPI-IO. ROMIO makes a best effort but
there's no way to guarantee you won't corrupt a block of data (NFS
Ok. But how can I know the type of filesystem my users will work on?
For small jobs, they may have data on NFS and don
for v5.0.x PRs. It may be a few days until all of our CI is enabled
on v5.0.x.
Thanks everyone for your continued commitment to Open MPI's success.
Josh Ladd, Austen Lauria, and Geoff Paulsen - v5.0 RMs
--
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université
39 matches
Mail list logo
