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

[Boris B. <bor...@bu...>]

Awesome thanks for the updates. Ill pull in the changes and give them a try
in the next couple of days - will post back here if there are any major
hicups.

Thanks for the changes & clarifications,
- Boris

On Fri, Mar 24, 2017 at 6:23 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 22 Mar 2017, Roy Stogner wrote:
>
> On Mon, 20 Mar 2017, Roy Stogner wrote:
>>
>>  I'm starting a branch to do some of these things; I'll let you know
>>>  after I push to GitHub.
>>>
>>
>> You can see the start of things at roystgnr/projection_matrix
>>
>> Some questions that are coming up:
>>
>> In the complex-valued problem case, are we going to want projection
>> matrices to be SparseMatrix<Number> or can we still get away with
>> SparseMatrix<Real>?
>>
>> In the heterogeneous Dirichlet boundary condition case, prolongation
>> operations are *not* linear operators unless the Dirichlet BC is
>> contained in the trace of the finite element space.  I'm going to
>> cross my fingers and hope we can ignore that in the context of
>> multigrid solvers, but if anyone knows of any papers that discuss this
>> issue I'd love to hear about it.
>>
>
> And some more questions, this time directed at my senior libMesh
> developers:
>
> Whose idea was SparseMatrix::attach_dof_map??  Were we *trying* to
> stop people from ever creating more than just the one sort of square
> matrix?
>
> I finished the code for filling our projection matrices, I dug into
> the APIs to figure out what I needed to do to get the sparsity pattern
> right first... and I find out it's impossible with the existing API.
>
> Boris:
>
> In the next few months, I'll try to find time at some point to clean
> up the SparseMatrix/PetscMatrix interface.  You won't want to wait for
> that.
>
> In the near term, see if roystgnr/projection_matrix is enough to get
> you started, after you replace each of the APIs-which-use-SparseMatrix
> with APIs-which-use-raw-PETSc-Mat.  I haven't tested the code for
> obvious reasons, but it's all there and all the metaprogramming
> hurdles have been jumped.
> ---
> Roy
>