On 2013-12-08 15:12, Jan Blechta wrote:
On Sun, 08 Dec 2013 14:38:44 +0000
"Garth N. Wells" <[email protected]> wrote:
On 2013-12-07 17:13, Jan Blechta wrote:
> On Fri, 06 Dec 2013 17:13:12 +0000
> "Garth N. Wells" <[email protected]> wrote:
>
>> On 2013-12-06 13:54, Jan Blechta wrote:
>> > I'd like to introduce support for communicator being supplied by
>> > user, stored within mesh and used by other objects based on the
>> > mesh. There are few applications of this. Mikael has one being
>> > rather non-trivial, I
>> > think.
>> >
>>
>> Any object that requires an MPI communicator should take the
>> communicator as an argument. Our present design is way too simple,
>> and is flawed.
>
> Can you explain me, for example, what should be comm stored within
> FunctionSpace instance (different from comm of underlying Mesh)
> useful for?
>
A FunctionSpace probably doesn't require a communicator.
Ok, now I see it - there may be other objects that require a
communicator but are not based on Mesh. For example linear algebra
objects.
Yes.
A Function or FunctionSpace may want to check that the objects on which
they depend (e.g. Mesh and DofMap) share a compatible communicator.
Garth
Jan
Garth
> Jan
>
>>
>> > To achieve this it will require some changes in the interface,
>> > roughly sketched:
>> >
>> > - MPICommunicator::MPICommunicator()
>> > + MPICommunicator::MPICommunicator(const MPI_Comm&
>> > comm=MPI_COMM_WORLD)
>> >
>> > + MPICommunicator::MPICommunicator(const MPICommunicator& comm)
>> >
>> > merging classes MPI, MPINonbocking into MPICommunicator
>> >
>> > + Mesh::Mesh(..., shared_ptr<MPICommunicator>
>> > comm=MPICommunicator())
>> >
>> > + UnitIntervalMesh(..., comm), ...
>> >
>>
>> Seems a bit complicated to me.
>>
>> As a starting point, I would suggest changing the interface to all
>> the utility functions in dolfin/common/MPI.h to accept an MPI
>> communicator. The next stage is to propagate this upwards. For
>> simplicity and backwards compatibility we should have two
>> interfaces at the top level interfaces - one that assumes the
>> default communicator, and one that takes the communicator as an
>> argument.
>>
>> Garth
>>
>> > Importat question is which type of comm to reaveal to user in C++
>> > DOLFIN, pyDOLFIN to make it as much as possibly compatible with
>> > other libraries, like boost, PETSc, mpi4py, petsc4py.
>> >
>> > Jan
>> > _______________________________________________
>> > fenics mailing list
>> > [email protected]
>> > http://fenicsproject.org/mailman/listinfo/fenics
>> _______________________________________________
>> fenics mailing list
>> [email protected]
>> http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
