On Fri, 8 Sep 2017, Michael Povolotskyi wrote:
still let me share with you the stack trace.
It works for me now with mpich, but if I can help to improve libmesh
portability I would be glad to do it.
I originally thought this looked a little like a local linkage mixup,
in which case there'd be no point in working on it... but I certainly
don't see anything obviously mixed up in those library names.
Here is the trace from the 1st MPI process.
On the 2nd it looks the same.
They're both stuck in the receive() of a send_receive()??
If you want me to print something in the debugger, I'll be happy to do it.
It would be good to verify that they're blocking, not infinite
looping. If they're blocking, I suppose you could verify that the
recv_tag is MPI_ANY_TAG. If a receive with MPI_ANY_TAG really isn't
receiving a just-sent message, then I'd just as soon chalk the problem
up to "screwy local MPI build" and forget about it, so long as MPICH2
is still working for you. I wasted too much time recently trying to
figure out how to workaround a bug in an old MKL version before I
became sane and just switched to a newer MKL.
However, if there's an infinite loop going on, then we might be able
to find something strange going on in the libMesh logic, and if you
could reproduce it with the git master then I'd love more help
tracking it down.
---
Roy
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
