Enriched elements

[rebpoli]

Hi

I am looking for an enriched element (where the basis functions are hybrid CG+DG).

The best from the user code perspective would be to embed such element into the library core. (fe_family=MY_ENRICHED_STUFF)
Exposing the calculations in the system assembly is not a big deal either.

Do you have any suggestion from past experience or code I should look at?

Renato

[roystgnr]

I vaguely remember a user many years ago emulating an enriched element by using two variables, one continuous and the other not, in the same way that you might use N scalar-valued elements to emulate (limited types of) N-d vector-valued elements. I don't recall whether it got more complicated than that (surely that would have been underdetermined without also adding constraints?) or whether it worked well though.

Can you describe a simple case, maybe a 1D or 2D basis example?

[rebpoli]

Hi, A reference paper would be https://doi.org/10.1137/15M1041109 . See equation (3.2). It is basically a composition of a continuous and a discontinuous space. The discretization strategy resembles a DG/Nitsche/IP. Ideally, I think of an element with a composite shape function so it becomes transparent for the user code. A linear TRI3, for example, would have 4 nodes: 3 for the CG shape function and 1 for the DG. I can also think of it as a Lagrange multiplier, with a discontinuous pressure variable. I can build an advection-diffusion example with the dual-var strategy and then try to migrate into a cleaner code (new element? new FE Family?). I need to control the enrichment on an element-by-element basis - similar to a hp-refinement. I am not sure it is worth the effort of modifying libMesh core, though. Perhaps the dual-var approach is just enough. Renato

…

On Mon, Aug 25, 2025 at 8:31 PM roystgnr ***@***.***> wrote: I vaguely remember a user many years ago emulating an enriched element by using two variables, one continuous and the other not, in the same way that you might use N scalar-valued elements to emulate (limited types of) N-d vector-valued elements. I don't recall whether it got more complicated than that (surely that would have been underdetermined without also adding constraints?) or whether it worked well though. Can you describe a simple case, maybe a 1D or 2D basis example? — Reply to this email directly, view it on GitHub <#4233 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER3B26FBLYNQJSSP6F33PO2FNAVCNFSM6AAAAACEUYETZ2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRRGYYDANI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[roystgnr]

Thanks! Yeah, I'd actually expect the dual-var approach to work fine here; if it's just piecewise constants being added to the approximation space then I think you only get like one redundant dimension (the everywhere-constant function, expressible in either sub-basis) over the whole mesh, so not much trouble constraining that away. And I guess you don't even get that, if you're not adding the enrichment everywhere in the mesh?

Whether you add a new family or not, the most straightforward way to handle element-by-element enrichment is with subdomain-restricted variables. Either your second variable is only active on the enriched subdomain, or you have a plain CG variable active on the non-enriched subdomain and a CG+DG variable active on the enriched subdomain.

Actually, when I put it like that, it makes the dual-var approach sound better. With the CG-here, CG+DG-there approach, you'd have to have constraints on the interface to force the CG DoFs to be equal. With the CG-everywhere, DG-there approach, everything just behaves like you'd expect.

You could abuse p-refinement flags rather than subdomain-restricted variables to handle the element-by-element enrichment with a single variable of a new FEFamily, and aesthetically that "feels" better to me, but it also means you'd never be able to combine enrichment with real p-refinement, or even with non-enriched variables.

If you weren't doing element-by-element enrichment then I'd have said the "right" thing do do is a new FEFamily, that basically wraps an existing family while adding the new complication, sort of like the RATIONAL_BERNSTEIN elements do to BERNSTEIN.

We could squeeze one more byte into Elem before we run out of padding in typical configurations and start taking up more memory, so it wouldn't be out of the question to use that to store a bit array for things like "is_enriched", at which point you could do this properly with a single variable without conflicts with p refinement or anything else. I'd definitely start with the dual-var approach for testing, though.

[rebpoli]

Thanks! Yeah, I'd actually expect the dual-var approach to work fine here; if it's just piecewise constants being added to the approximation space then I think you only get like one redundant dimension (the everywhere-constant function, expressible in either sub-basis) over the whole mesh, so not much trouble constraining that away. And I guess you don't even get that, if you're not adding the enrichment everywhere in the mesh?

I dont think this is a problem. The enrichment adds a conservation constrain, similar to a Lagrange multiplier or DG. Small overhead for the benefit, I would say. The additional DG/IP terms tie the redundancy (I believe)

Actually, when I put it like that, it makes the dual-var approach sound better. With the CG-here, CG+DG-there approach, you'd have to have constraints on the interface to force the CG DoFs to be equal. With the CG-everywhere, DG-there approach, everything just behaves like you'd expect.

This sounds like the best argument for the dual-var approach. Makes perfect sense to me. Then I just constrain the DG DoFs to neighboring plain CG elements (domain boundary), no big deal. That shall work.

We could squeeze one more byte into Elem before we run out of padding in typical configurations and start taking up more memory, so it wouldn't be out of the question to use that to store a bit array for things like "is_enriched", at which point you could do this properly with a single variable without conflicts with p refinement or anything else. I'd definitely start with the dual-var approach for testing, though.

Agree. So my understanding is that the library as-is has enough to handle the enrichment. I already started the design where all these flags and machinery is handled in the user side. So far it does not look as bad as I anticipated, in fact. Thank you. Renato