[dune-functions] [Dune-devel] hierarchicVectorWrapper and hierarchicMatrixWrapper

[Carsten Gräser]

Hi Simon,

Am 21.02.2018 um 14:30 schrieb Simon Praetorius:
> Hi Carsten,
> 
> Zitat von Carsten Gräser <graeser at mi.fu-berlin.de>:
[...]
>> This looks interesting. Since one cannot terminate the
>> recursion depending on the dynamic length of the multi-index
>> I chose to terminate depending on the data structure.
>> While dune-functions is intended to work with scalar
>> coefficients (vector-valued bases can naturally be
>> implemented as power-*), prescribing the scalar
>> coefficient type is nasty. On the other hand I do not
>> see any possibility to avoid a common coefficient type
>> if you have dynamic multi-indices.
> 
> A common coefficient type is really a tricky problem. For
> MultiTypeVector<std::vector<std::bitset<N>>, std::vector<bool>>
> for example, there is no common value type. Both leaf vectors
> return different (non-compatible) proxies for the boolean values.
that's why it is _impossible_ to implement a non-const
access to this with a dynamic index (unless you implement
some possibly slow type-erasure).

>> What I like about the approach you outlined, is that
>> it enriches the information about the index tree structure.
>> But hard-coding the Blocked/Flat information is unfortunate,
>> because dune-functions does not require that a basis
>> is implemented as DefaultGlobalBasis<PreBasis> (see
>> my recent mail on the renaming). Implementing your
>> own basis without this mechanism is totally fine.
> 
> OK. I simply have not seen/tried out any basis that is not
> a DefaultGlobalBasis. Some parts of my implementation are
> based on the PreBasis structure of Power/Composite PreBases
> This is probably too restrictive, but I have no other idea currently.
The problem is not that the structure is needed to implement
this information. The problem is that the interface depends
on this.

>> I'd rather like to view this as some abstract
>> information about the index set additionally to
>> size(prefix). For DefaultLocalIndexSet it could
>> be implemented using the knowledge about the
>> IndexMergingStrategies. My rough idea about this
>> was to have something like isStatic(prefix)
>> and staticSize(prefix). I have the impression
>> that your proposal essentially does this, but I'll
>> have to look into the details.
> 
> The IndexMergingStrategy is not part of the concept of PreBasis
> (NodeFactory).
> I have to think about this. Maybe then the nesting-structure can only
> be extracted by extending the interface in an intrusive way.
As I said above: You have to distiguish the interface
and its implementation.

>> BTW:
>> There's an alternative approach that I had in mind.
>> The whole problem arises from having dynamically
>> sized global multi-indices which are unavoidable
>> if we want to map our _flat_ local indices to global
>> multi-indices. If we additionally provide a method
>> index(treePath,index) with a static treePath to
>> a leaf and an index of the basis function only within
>> this leaf, then this could make use of the static
>> information and return a hybrid (static-dynamic)
>> version of the multi-index. Resolving this would
>> be a trivial recursion. But it would also require
>> to implement the loop in th local->global transformation
>> in user code to a tree traversal.
> 
> More static indexing and static looping makes the recursion simpler, but
> also the error-messages more unreadable. Currently, if something goes
> wrong I got error-messages where just 1 line fills up the whole display.
> 
> I decided to use dynamic indexing and dynamic looping if possible. Only
> for the MultiType blocks a static loop is used.
More important than the static loop itself is to
be able to determine the multi-index size statically.
However, I also dislike the dynamic->static translation
needed for fully dynamic indices.

Best,
Carsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20180223/a71faf7e/attachment.sig>