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

[Simon Praetorius]

Hi Carsten,

Zitat von Carsten Gräser <graeser at mi.fu-berlin.de>:

> It can be done for matrices in (almost) exactly the same way.
> I did it for dune-fufem. However, there's one issue when using
> non-uniform multi-indices to access a matrix:
>
> For non-diagonal entries you will query entries where the
> row- and column-multi-index have a different length. In
> this case some indices conceptually refer to a single-row
> matrix that does not require a column index (or the other
> way around). Since our matrix implementations do not support
> this, I solved this in dune-fufem by providing wrappers that
> essentially tag a matrix in the nested matrix structure to
> be single-row or single-column. Then the recursive multi-index
> resolver (working similar to the vector case) can smuggle
> in a [0] for the missing index.
>
> This is not in dune-functions, because some considered this
> a feature of a discretization module that should thus not
> be part of a dune-functions. I think that this is debatable
> though.

OK, maybe it is possible to implement the wrappers based on the  
coefficient type.
My problem was also related to the fact, that my vectors and matrices  
can return
a proxy instead of a value reference. In the case of MTL4 matrices,  
for example,
an inserter-proxy is returned for sparse matrices that builds up the  
sparsity structure
during insertion of new elntries. Although all blocks are build with  
the same matrix
and thus have the same proxy as coefficient type, this type is not  
easily available
and in case of dynamic-size multiindices not easily extracted for the matrix.


> 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.


> 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.


> 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.


> 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.


> Best,
> Carsten

Best wishes,
Simon



-- 
Dr. Simon Praetorius
Institut für Wissenschaftliches Rechnen
Fakultät Mathematik
Technische Universität Dresden
Tel.: TUD-34432
Mail: simon.praetorius at tu-dresden.de
Web: www.math.tu-dresden.de/~spraetor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5753 bytes
Desc: S/MIME-Signatur
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20180221/84975b69/attachment.bin>