[Dune] ALUSimplexGrid<3, 3>::loadBalance(DataHandle&) appears to expect something else than a DataHandle

[Jö Fahlke]

Am Sat, 20. Nov 2010, 14:00:46 +0100 schrieb Martin Nolte:
> When wrapping this loadBalance method for GeometryGrid, I thought this interface
> unnecessarily complicated and tried to use the one we all know, i.e., I wrote an
> adapter class transforming the DataHandleIF into the DataHandle expected by
> ALUGrid. If you pass a DataHandleIF (it has to be the interface class!) to
> ALUGrid, this adapter will automatically be plugged in. Otherwise, ALUGrid
> assumes that it's "native" data handle is provided. In the dune-grid school we
> did in 2009 in Heidelberg, we successfully used the DataHandleIF version.

I assume that you mean CommDataHandleIF when you talk about ALUGrid, since
DataHandleIF only appears in the context of GeometryGrid.

> To be a bit more specific, ALUGrid provides to loadBalance methods that
> communicate data:
> 
>   template< class T, class I >
>   bool loadBalance ( DataHandleIF< T, I > &dataHandle );
> 
>   template< class DataHandle >
>   bool loadBalance ( DataHandle &dataHandle );
> 
> The first method is what you expected, the second one is ALUGrid's "native" version.

Indead I tried the first and thought deriving my data handle from
CommDataHandleIF would be enough.  However, the second method still wins in
that case, since it will provide an "exact match", while the first method
requires a "derived-to-base conversion".  To make it work, I explicitly have
to cast my datahandle to the interface:

| grid.loadBalance
|   (static_cast<CommDataHandleIF<DH, typename DH::DataType>&>(dh));

This is ugly, because it will not work in general: it assumes that the data
handle DH is directly derived from CommDataHandleIF.  It will work portably
enough in my case, though, since I know the type of my datahandle exactly.

I tried different ideas how to change ALUGrid to lift that restriction by
using enable_if/disable_if and checking whether the data handle provided to
loadBalance() is derived from CommDataHandleIF; ultimately I always had to
make assumtions which I know are violated by some of the data handles in
existance.  The best solution I came up with instead was to derive
CommDataHandleIF from a non-template class CommDataHandleTag and then assume
anything that is (directly or indirectly) derived from CommDataHandleTag is a
valid Dune-datahandle.  This would however be an interface change.  If anyone
is interrested, feel free to ask for more.

> To me, the use of DataHandleIF seems more intuitive. On the other hand, it is
> misuse of the interface in the following sense:
> a) You can only pass one data handle. Hence, this data handle has to be capable
> of gathering / scattering all data. This is only possible, if all data has a
> common "Data" type (actually ALUGrid does not care for this type internally).

I consider this a severe restriction.  I might actually need to communicate
data of different type in the future, however it is not a pressing matter
right now.

> b) DataHandleIF was designed to transfer data on one grid view (as they are
> called today). During load balancing, we transfer data on the whole hierarchy.
> Consequently, if I want to communicate one value on the leaf level, there are
> two possibilities: Communicating nothing on the non-leafs leads to fixed-size
> returning false. Communicating a dummy value on the non-leafs increases the
> amount of data to be transferred.

How high is the cost of fixed-size==false?  In my case I have that anyway
since I want to communicate on the boundary-codim 1 entities, but not on any
non-boundary ones.

> Someday, this issue will have to be discussed on a developer meeting. This
> discussion won't make sense until there is another grid implementation that
> supports dynamic load balancing, though.

Thank you for your quite insightful answer,
Jö.

-- 
Das Leben ist eine Krankheit, die tödlich endet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20101120/99763f1a/attachment.sig>