[Dune] A question on CollectiveCommunication

[Aleksejs Fomins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear All,

Thank you for your replies, they are very useful.

There is still 1 thing I do not understand.

You say I can communicate a vector using &A[0]. Does this also apply
to the DataHandle interface? Because in DataHandle the message buffer
read() and write() only take 1 argument of type T. How would it then
know the length of the array, given that it is not explicitly
specified that T is an array?

Regards,
Aleksejs


On 19/01/15 13:22, Markus Blatt wrote:
> Hi,
> 
> On Mon, Jan 19, 2015 at 12:36:23PM +0100, Steffen Müthing wrote:
>> 
>> Am 19.01.2015 um 11:51 schrieb Aleksejs Fomins
>> <aleksejs.fomins at lspr.ch>:
>> 
>>> Signierter PGP Teil Dear Dune,
>>> 
>>> I am trying to understand the paradigm of the communication
>>> used in Dune
>>> 
>>> The question concerns the following Dune::CommDataHandleIF<
>>> DataHandleImp, DataTypeImp >
>>> 
>>> and
>>> 
>>> int Dune::CollectiveCommunication< C >::gather( T * in, T *
>>> out, int len, int root) const
>>> 
>>> In both cases we define a template parameter which defines the
>>> data type to be communicated. As I understood from discussions
>>> with Marcus and Peter, internally the communication is
>>> performed using MPI_BYTE communication, i.e. sending size_of(T)
>>> data from a given address to a given address.
>>> 
>>> It looks to me that this should not work for T = some stl
>>> object, because: 1) If T has variable size, and we are passing
>>> a pointer to the array of T's in gather, then gather has no
>>> information on the length of each individual T 2) If I would
>>> like to communicate T = std::vector<int>, would not the 
>>> internal implementation of vector contain a pointer to an array
>>> for the current processor?
> 
> Then please pass &(vec[0]) to the method.
>>> 
>>> That said, the question is as follows:
>>> 
>>> Is dune communication interface intended to handle standard stl
>>> types? If no, which DataTypes are expected/allowed to be
>>> communicated?
>> 
>> as you have correctly figured out, all internal communication
>> happens by means of a char buffer, so the only kind of data you
>> can safely communicate are POD types.
> 
> At least for ColllectiveCommunication This is not entirely correct.
> You can send any type that the size can be deduced at compile time.
> This includes pods. The default is to query the size of the type,
> convert it bytes, and send. One can specialize this behaviour using
> templates. There are a number of specializations that use MPI to 
> store and retrieve the values. See e.g.
> dune/common/parallel/mpitraits.hh. This mechanism is also used by 
> the VariableSizeCommunicator.
> 
> Unfortunately, the grid classes are much dumber and always use the 
> default above.
> 
>> YaspGrid was bitten by this some time ago because it tried to
>> send objects of a class with virtual functions. MPI then happily
>> copied the vtable pointer to the target machine. That machine
>> then crashed as soon as it tried to dereference the pointer for a
>> function call.
>> 
>> TL;DR: only communicate POD data.
> 
> Only compute data where you can query the size based only on the 
> information of the type.
> 
> Markus
> 
> 
> 
> _______________________________________________ Dune mailing list 
> Dune at dune-project.org 
> http://lists.dune-project.org/mailman/listinfo/dune
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUvS6EAAoJEDkNM7UOEwMZhrcQALSNIhHRp5hJgxGvJ5DbxCrj
uf7soPh/Cf/N+P5DtPC1kjreLwP0wr3U34ocqOl9j7oop8deRkLqpnLKX6P/QRYG
nj+mo0acNLPe0OcrXdsh7gCBKS/+0+W9lV3U/LFZpfLazB2fWpCrlfU15l9Q1jcd
Z9ieJ0KV98a6b3C+rMiQv8uQtMQ9GufrWHK6szYnpQJ9zGfQUSCOEHsj4bhRV1HE
LSX1rvK2uPmXMrZjrbhBxJDAYElSy89YJw+Wzd1PhJGa3QbGO55+MwnqW83N+w4f
qRKAuilpyzVEHc9csdoiwo5j/TuC3bQzfKEbyqZ+60qFqqN4IxCD+eT6I1lmHbWI
PsB9ftMIo9ugx95knkAEmVufmAO5PjdfCTkVBLDASXQ7N8iz+Q15kx7IPxytlGbj
fA5kW+Ba6Q6YZi1KXMZEkDdKSU4w1aTi4m3wtIjnKANYqjfHU97pal/IFRgNsl7x
LoycUzMgL7SI2hfOKCeCRDiim3XwLo0JPs3ki4PZ4xTNtcAibL330o9gBTW+KrR2
LsANO6HI7SrdohU37x0vMjH/K8VGq5L3qxQcVTkZz+AT7Z1+a/P3K4c7zJiGCwDb
To6hsGpjqkrX0csQ5/vEGsrpZ5bx7lPd1XCpKJxpA+SZeiQC9nwZnlYlkKLGp5YY
X8LGN2pe+VG7vFc/f5D2
=QTdX
-----END PGP SIGNATURE-----