Extensibility of FE Objects

[pbauman]

Context:

• I want to tinker with some non-standard finite elements that may or may not end up being appropriate to add to the library
• I would like to tinker with adding some exotic finite elements

Issue:

• FEAbstract::build() is static and, therefore, cannot be overridden. This means if I want to add a new finite element, I need to intrusively change libMesh internally, particularly if I want the element to be used by, e.g., FEMContext.
• It might be nice if I could tinker in my app without having to go into the guts of the library to add a new FE object.

An idea:

• We can add an FEFactory (or whatever name you life) object that has a virtual build() (or whatever name you like) whose default implementation is just calling FEAbstract::build().
• This object can be fed to FEMContext and used in place of the existing static call.

I've not exhaustively searched the library to see how intrusive this would be, but at least wanted to kick off the discussion for thoughts or better ideas or declaration that I missed something obvious and should get another cup of coffee.

[pbauman]

FEInterface could be a problem.

[roystgnr]

Sorry to be late to the party; I've been on vacation and then catching up from vacation.

John said he pinged you privately, which is always a good instinct when business collaborations are concerned, but I don't think there are any secret plans here so we can at least talk about general details publicly: we'll likely have other collaborators wanting to make essentially these changes (among other changes for flexibility) for partially the same reasons.

I'm in favor as long as the changes don't end up being too intrusive to maintain and don't end up having too significant a runtime cost ... and you're currently making me worry less about the first problem: if you're using the same new API then it'll be more likely that we'll have some decent open source test coverage, won't have to work as hard to avoid/fix future regressions, and will have proof-by-example that this refactoring will be worthwhile to a variety of users.

FEInterface was one problem I noticed, but I think we can handle that by putting the hard work in the default: branches of the switch statements there - adding nearly zero cost for integrated elements with their own switch branches, but then we can be more sophisticated in what we do to search for the right implementation for dynamically loaded elements.

The other problem in their case was that we might have a situation like we did with subdivision surfaces where there's an extended stencil for which the standard dof_indices code is inadequate, but we'll lump that all into the same if (weird_case) branch there to avoid getting too costly, and that may not affect your elements depending on your definition of "exotic".

For your possible definitions of "exotic", on the other hand, I wonder if our existing transformation functions are inadequate - any chance H1FETransformation and HCurlFETransformation might be getting a new friend? :-)

[pbauman]

OK, cool. I'll be interested to see how it evolves. The non-standard ones I had in mind that probably don't belong in the library are constant-enriched linear elements.

any chance H1FETransformation and HCurlFETransformation might be getting a new friend? :-)

:D Indeed, some HDiv conforming were on the radar. I'm pretty scatter brained ATM because I want to tinker with a bunch of things but only have a few hours per week, so who knows when I'll actually get anything done.

[roystgnr]

constant-enriched linear elements

So you'd have nodal DoFs like any other linear C0, but then you'd have a constant "bubble function" so you'd be discontinous, but you'd only have the constant so you wouldn't have the full space of all our discontinuous linears? Interesting. I'm then guessing there's some formulation where this thing obviates the need for a stabilization term and meets LBB anyway?

If I'm actually right about all that, I'd say it belongs in the library, but pretend I didn't say so, because I'd like to see it as an example case for third-party FE specializations even more.

[pbauman]

So you'd have nodal DoFs like any other linear C0, but then you'd have a constant "bubble function" so you'd be discontinous, but you'd only have the constant so you wouldn't have the full space of all our discontinuous linears?

Yup.

Interesting. I'm then guessing there's some formulation where this thing obviates the need for a stabilization term and meets LBB anyway?

It's more about better mass conservation, but yeah they're inf-sup stable. https://link.springer.com/article/10.1007/s10915-011-9549-4 (email me for pdf)

If I'm actually right about all that, I'd say it belongs in the library, but pretend I didn't say so, because I'd like to see it as an example case for third-party FE specializations even more.

XD

[lindsayad]

We've been having some discussion about conservation, with relation to some more exotic bases, over on #3318

[vikramvgarg]

Vikram Garg

On Fri, Apr 22, 2022 at 3:50 PM Paul T. Bauman ***@***.***> wrote: So you'd have nodal DoFs like any other linear C0, but then you'd have a constant "bubble function" so you'd be discontinous, but you'd only have the constant so you wouldn't have the full space of all our discontinuous linears? Yup. Interesting. I'm then guessing there's some formulation where this thing obviates the need for a stabilization term and meets LBB anyway? It's more about better mass conservation, but yeah they're inf-sup stable. https://link.springer.com/article/10.1007/s10915-011-9549-4 (email me for pdf)

Does better mass conservation also mean better momentum conservation, which is perhaps a goal that is just as or even more important ? The error estimate I have seen for Taylor Hood for example has higher order norms of the velocity and pressure.

…

If I'm actually right about all that, I'd say it belongs in the library, but pretend I didn't say so, because I'd like to see it as an example case for third-party FE specializations even more. XD — Reply to this email directly, view it on GitHub <#3226 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGNEEKBV5XTAK3K4LIO3O3VGMULXANCNFSM5S7BJMRQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lindsayad]

I wonder if it is about the same effort to make FE extensible and make the new FE in an app as it is to add a new FE in the library? The unfortunate part about adding extensibility is that it discourages somewhat the contribution of new FE types directly to the library. Even if an exotic new type ends up not being super useful for some application, I don’t think there’s much harm in having it available at the library level

[roystgnr]

We've done more than a few rounds of "add something in an app or in middleware, then migrate it to the library when we're sure the API is solid" in the past. I really like that workflow for any design that we might consider "experimental". I'm thinking of cases where the additions were made by people who were already libMesh developers, though ... perhaps being able to do a completely independent extension would remove an incentive for app developers to become libMesh developers in the first place? And in the specific case of FE types, if the API is solid enough to create an extension capability then there's not much left to be "experimental" enough to not just put a new FE into the library directly.

[pbauman]

"add something in an app or in middleware, then migrate it to the library when we're sure the API is solid" in the past. I really like that workflow for any design that we might consider "experimental".

+1 (not that my vote really should count for anything anymore)

I wonder if it is about the same effort to make FE extensible and make the new FE in an app as it is to add a new FE in the library?

Probably, but that's the problem, IMHO. Also, as it stands, even just adding it to the library is pretty cumbersome as I recall (it's been awhile though). It'd be nice to streamline all that as much as is reasonable.