Essential boundary conditions in CeedOperator

[barker29]

How should a user think about essential boundary conditions in a CeedOperator?

If I understand correctly, the CeedOperator never includes essential boundary conditions, and these are instead handled by the frontend code (eg DMPlex in Petsc or FiniteElementSpace in MFEM). This makes a certain amount of sense, but on the other hand from a mathematical perspective these boundary conditions are really a part of the "Operator".

This comes up because of a project we have developing solvers for "matrix-free" operators, one particular target of which is the CeedOperator object. Supposing we develop some amazing magical way to build a coarse CeedOperator from a given fine one, we need to also separately coarsen the essential boundary conditions. This would be more convenient if these were included somehow in the operator interface.

This is a long-winded way of asking if it may make sense for the Ceed operator to be of the form

A = Z^T P^T G^T B^T D B G P Z

with an additional Z operator that encodes essential boundary conditions. Does that make any sense or is it out of scope for libCEED?

[jeremylt]

P is outside of the scope of libCEED, so Z in your formulation above would be as well. We don't deal with the T-vector, or total solution vector. We only touch the L-vector, or local solution vector.

In which way are you interested in coarsening a libCEED operator? p-coarsening is pretty natural and we have examples of p-coarsening in examples/petsc/multigrid.c and examples/solids/elasticity.c. In these examples, we handle the essential BCs with the parallel mesh management, so the coarsening of the BCs also lives there.

I have been meaning to add higher level interface to handle p-coarsening an operator.

[barker29]

Thank you, that answers my question.

We've looked at the p-multigrid examples - what we have in mind is something a lot like that, but hopefully more "automatic", knowing as little as possible about the mesh.

[jeremylt]

I should be able to pretty easily add an interface to provide the prolongation, restriction (in the multigrid sense) and coarse versions of a given libCEED operator, but the user would have to provide the element restriction, G, for the new coarse mesh. There would be some details to iron out about how to handle passive inputs.

@camierjs would this interface be helpful to MFEM as I work on MFEM + libCEED + CUDA preconditioning this summer?

[camierjs]

If this interface would help porting ex26 through libCEED + CUDA, I think that should be definitely useful for the project.

[jedbrown]

How would it help? I think essential BCs are usually imposed in the T-vector or as part of the T->L operation, both of which are out of scope for libCEED. There are some cases, like nonlinear slip, where it might become part of the CeedOperator, though such dofs are usually not eliminated so I'm not sure what you'd like libCEED to add. We do want to make integration easy so long as it doesn't increase complexity too much.

[camierjs]

I thought it would help for the construction of the multigrid hierarchy: I see that the essential BCs given by the user are used throughout the code. If it's not the case, sure: let's not complicate the library.

[jeremylt]

It looks like MFEM ex26 is pretty close to what we have in our multigrid.c example in the PETSc folder. I can definitely provide that functionality in a cleaner way + add the GPU support. See issue #541