Re: [Libmesh-devel] Implementing multigrid style projections through GenericProjector interface

[Roy S. <roy...@ic...>]

On Fri, 17 Mar 2017, Boris Boutkov wrote:

> I've been spending some time thinking about how to neatly implement
> multigrid projections through the existing  GenericProjector
> interface and would like some input on the following points.

Sorry for the late response; I wasn't sure I understood your
questions, so I took advantage of having Paul Bauman here in person
today to interrogate him about the problems.

> - In order to properly insert local projection matrices into the
> global projection I need some additional information in the
> ProjectionAction parameter of the GenericProjector. Specifically, I
> need access to the old dof information (as well as the existing new
> dof info) as this dictates where the local projection matrix gets
> inserted into the global one.

Right!  This is why FValue will need to be a sparse array type like
MetaPhysicL::DynamicSparseNumberArray.

> While it seemed originally that I could hijack the Fvalue parameter
> information and squeeze old dof info in there, now this appears to
> be a problem since Fvalue is also used in Fe all throughout the
> Ke/Fe solves.

In theory, that's exactly what we want!  DenseMatrix::cholesky_solve()
takes a second template type, precisely so we can do things like
using a DenseMatrix<Real> to solve a problem with DenseVector<DSNA>
data and solution.

In practice... we don't even bother to instantiate that function with
any combinations other than Real+Real, Real+Complex, and (if
--enable-complex) Complex+Complex.  So we probably need to move those
function definitions into a dense_matrix_impl.h header that we can
include elsewhere for when we want to instantiate Real+CrazyOOClass.

I'm starting a branch to do some of these things; I'll let you know
after I push to GitHub.

> - Additionally, it seems like we may need to update the
> ProjectionAction interface to take in Ke and Fe as well.

No!  As long as you can solve for Ue, making it another DSNA, then
each entry of Ue is itself a simple matrix row.  No need for Ke
afterward or Fe afterward - you get the column index for each entry
from the indices in the sparse array.
---
Roy