Unbounded poisson solve 3d

[fankiat]

Fixes #133 , merge after #132 .

@bhosale2 in this PR the MPIDomainDoublingCommunicator3D (currently named) is actually generic for both 2d and 3d in its current form now. In other words, that same communicator can be used for UnboundedPoissonSolverMPI2D. However, the communicator includes a few abstractions, which may or may not be straightforward, but I've placed some comments on some of the steps used. Nonetheless, there are a few things I need a second opinion on.

1. Since the domain doubling communicator is now a generic one, should we put this communicator elsewhere? If we do, where do you think is the best place, given that we have mpi_utils.py, mpi_utils_2d.py, and mpi_utils_3d.py?
2. Following up on that, depending on what we do, maybe it's a good time to revisit Refactor MPI utils #91 — making a dimension-agnostic mpi_utils.py?

The above points of course only make sense (somewhat) to discuss further if we decide to actually move the domain doubling communicator to a more appropriate place. If we keep the domain doubling communicators separated in 2d and 3d, we can probably keep the code in this PR as is, and keep the communicator in the 2d poisson solver as a simpler code for reference (where the communicator is somewhat hardcoded and assumes only slab decomposition). Finally, depending on what we do here, I will come up with some test cases for the communicator, which I believe works correctly, given the poisson solver gives the right results.

[bhosale2]

@fankiat I feel it should not be called utils anymore, since its an important sub-module of the library. Maybe you can think of moving these MPI parts to a sub-module under sopht-mpi called mpi_comm or a better name? This should happen in a separate PR ideally.

[fankiat]

@fankiat I feel it should not be called utils anymore, since its an important sub-module of the library. Maybe you can think of moving these MPI parts to a sub-module under sopht-mpi called mpi_comm or a better name? This should happen in a separate PR ideally.

Hmm.. That's one way to go about it I guess. Ok then, we can look into this in a separate PR after this PR is merged. Maybe we open an issue for the refactoring and I can take care of that issue accordingly. Thanks!

[bhosale2]

minor.

[bhosale2]

LGTM. @fankiat after this make sure you open an issue called Road to Graduation or so, and start listing the functionalities for scaling, running high res, global profiling, etc. to prioritize accordingly.