[gpaw-users] Different MPI worlds ASE vs. GPAW: small fix, big fix or migrating to mpi4py?

[Ask Hjorth Larsen]

Hi,

2018-08-08 9:59 GMT-05:00 Gaël Donval via gpaw-users
<gpaw-users at listserv.fysik.dtu.dk>:
> Hi,
>
> The test `generic/hydrogen.py` hangs with the pristine python
> interpreter with PARALLEL support provided in this MR:
>
>    https://gitlab.com/gpaw/gpaw/merge_requests/403
>
> This is caused by the ASE DB access part of the test:
>
>  * gpaw.mpi.rank gives the right rank.
>  * ase.parallel.rank always returns 0 ("DummyMPI()" is used because
>    _gpaw is then not built-in).
>
> I can submit an MR in ASE to fix that last point but I'm really
> starting to wonder if we shouldn't:
>
>  * at the very least separate mpi.c from _gpaw.c to avoid having MPI
>    coupling all other the place;
>  * migrate to mpi4py and keep it well-separated as well.

What is the motivation for separating MPI support from _gpaw?

>
> From Python's perspective, all the MPI stuff in `_gpaw` does not exist:
> it is only ever used in `gpaw.mpi` precisely to provide MPI. Yet it is
> everywhere: I'd really like to get rid of it.
>
> What do you think bout it?

Which is the exact thing that you would like to get rid of?

When you start gpaw-python it will immediately initialize all the MPI
stuff, guaranteeing that there can be no problem - but we can only do
that because we control the startup sequence in gpaw-python.

Probably it is a good idea to migrate to mpi4py in the long run from a
development perspective, but we often get very unpopular for adding
dependencies, so it is not something that I would push for unless
there are very good reasons to ditch the old framework.

Best regards
Ask

>
> Gaël
>
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users