[dune-pdelab] Sending bytes in communication breaks portability

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Fri Jun 27 13:23:22 CEST 2014


Hi Markus,

as Christian already said: That really is a general problem with the way the grid
DataHandles work: They only allow you to send a single datatype per transmission
(which doesn’t work in this case), so my ugly hack really is the only way to handle
the situation. Similar hacks are already present in e.g. the implementation of the
UG message buffer, which injects the per-entity data size into the data stream if
the data handle is not of fixed size.

On the other hand, as I explained in the commit messages, this change in behavior has
to be explicitly enabled on a per-GridFunctionSpace basis using a compile time switch.
This switch is disabled for all GridFunctionSpace implementations that are part of standard
PDELab; regular PDELab users will still get DataHandles that use the actual DataType
specified by the user (leaving stuff like breaking cross-Endianness compatibility to lower
levels like the grid… ;-) ).

As stated in the commit messages, I just need this support to be able to correctly support
communication for dune-multidomain. And because the creation of many data handles is
wired pretty deeply into the parallel solver infrastructure, I do need these additional hooks
in core PDELab to avoid reimplementing all of the parallel solvers in dune-multidomain just
to replace a couple of data handles.

But just to reiterate: This changes does *not* affect you unless you use dune-multidomain.

Steffen



Am 27.06.2014 um 12:32 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:

> Hi Markus,
> 
>> The implementation simply writes the size and data to a char array sends
>> this as bytes to the other processors. Unfortunately, this will break
>> behaviour that people expect from MPI libraries and
>> applications. Namely, that sending data between processes on different
>> hardware platforms works. With sending bytes this is not the case
>> anymore and might provoke rather hard to find errors in the
>> computations. (E.g. the size of size_t might be different or then
>> endianess and as a result what we reveive might not be what we send). 
> 
> This is a general issue in due and presumably many parts in dune will
> not work in heterogenerous setups.
> 
> The template MPI data wrappers in common do exactly the same, they
> fold everything into a char array and send this. While it is
> definitely a good idea to fix this particular case in pdelab, we will
> still have the general problem of sending data dune.
> 
> Christian
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20140627/54d16346/attachment.sig>


More information about the dune-pdelab mailing list