Boost logo

Glas :

Re: [glas] (no subject)

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2006-01-04 10:45:26


Talking about vectors of matrices, we need to define algorithms for those:
let v be a vector of matrices, so v[i] is a matrix,

Then norm_1 could be:
sum_i norm_1( v[i] )

max_i norm_inf(v[i])

and similarly for other norm functions.

For the inner product, trans(v)*w is then
sum_i trans(v[i]) * w[i]

Is this ok?


On Friday 14 October 2005 02:01, Wolfgang Bangerth wrote:
> In reply to an already several days old message:
> > I recall a demand for supporting vectors of matrices and matrices of
> > matrices. My opinion is that this should be another type of collection
> > where the value_type is still the value_type of the lowest level of
> > matrix in the nesting of matrices.
> There is definitely a demand for something like this, though I wouldn't
> suggest that implementing them as matrices of matrices is a particularly
> clever way to go.
> The application where this is important is when one can split a matrix
> into blocks. Typical applications are discretizations of vector-valued
> partial differential equations (think: mixed methods, saddle point
> problems) where instead of solving with a matrix directly, one would like
> to form Schur complements of its blocks. The right abstraction therefore
> is to consider the whole matrix as an array of submatrices (blocks).
> The way we implement this in deal.II (and I believe this is the correct
> way) is indeed as an array of matrices. One can access individual blocks,
> but if you try to access individual elements of the matrix, one gets a
> reference to the corresponding element in the block in which it resides.
> The BlockMatrix class therefore has a dual interface: access the blocks of
> the array through
> Matrix & block (const unsigned int block_i, const unsigned int block_j)
> and access the elements of the matrix through something like
> reference operator() (const unsigned int i, const unsigned int j) {
> return blocks[block_from_global(i)][block_from_global(j)]
> ->operator() (local_from_global(i), local_from_global(j));
> }
> Through the second interface, one can hide the actual storage scheme from
> algorithms that only expect a matrix, while the first interface allows to
> extract and operate on individual blocks.
> If, on the contrary, this would be implemented as matrices-of-matrices,
> then one would only have the first interface, but algorithms that just
> expect a transparent matrix object won't work because your operator()
> doesn't return individual entries of the matrix, but an entire block.
> For an example of an implementation of such concepts, feel free to take a
> look at
> Best
> Wolfgang
> -------------------------------------------------------------------------
> Wolfgang Bangerth email: bangerth_at_[hidden]
> www:
> _______________________________________________
> glas mailing list
> glas_at_[hidden]

Look at our unique training program and
Register on-line at
Karl Meerbergen
Free Field Technologies
16 place de l'Université
B-1348 Louvain-la-Neuve - BELGIUM
Company Phone:  +32 10 45 12 26
Company Fax:    +32 10 45 46 26
Mobile Phone:   +32 474 26 66 59
Home Phone:     +32 2 306 38 10
Axis Park Louvain-la-Neuve
rue Emile Francqui, 1
B-1435 Mont-Saint Guibert - BELGIUM
Same telephone, same fax, same mail