hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
K-ballo1 is now known as K-ballo
K-ballo has quit [Remote host closed the connection]
<hkaiser>
john98zakaria[m]: hpx can use different networking libraries for its communication
<hkaiser>
the tcp parcelport uses plain tcp, no mpi is involved
<hkaiser>
the mpi parcelport doesn't use tcp it's purely based on mpi
<hkaiser>
if your application uses mpi, then I'd suggest not to use the tcp parcelport in hpx
<hkaiser>
I'm not sure why using the mpi parcelport hangs, we rely on our own mpi communicator, so it shouldn't interfere with any other mpi calls
<hkaiser>
do you call mpi_init yourself?
<john98zakaria[m]>
hkaiser: Yes I did
<hkaiser>
HPX needs MPI_THREAD_MULTI
<john98zakaria[m]>
hkaiser: Is that an option?
<john98zakaria[m]>
> <@hkaiser:libera.chat> I'm not sure why using the mpi parcelport hangs, we rely on our own mpi communicator, so it shouldn't interfere with any other mpi calls
<john98zakaria[m]>
* Yes I did
<john98zakaria[m]>
theEnvironment = new boost::mpi::environment();
<hkaiser>
not really
<hkaiser>
we're currently investigating whether MPI_THREAD_FUNNELLED would be sufficient, though
<hkaiser>
john98zakaria[m]: boost::mpi::environment() allows you to specify the threading level
<john98zakaria[m]>
I hate inheriting code I didn't write
<hkaiser>
john98zakaria[m]: alternatively you delay the boost::mpi::environment(); until after HPX is up and running, then HPX will initialize mpi for you