Questions related to possibility of porting MOOSE to MFEM

[lindsayad]

I may think of more, but here are some key questions for determining feasibility of porting MOOSE to MFEM as the finite element backend:

• how easy is it for downstream applications to program nonlinear weak forms? Perusing some of the issues, it seems like it can be non-trivial but I could be reading wrong and/or the issues I’ve looked at are fairly old (I can link to these when I’m on my comp)
• What is the status of enabling contact methods? This is an important capability for our DOE NE program in which mechanical and thermal contact are important physical features for many of the advanced reactor concepts we are modeling

@tzanio i posted this here so that I might get input from multiple MFEM developers but I’m also happy to have this conversation on slack if you prefer

To be clear, if answers aren’t entirely positive, it doesn’t mean we’ll never port to MFEM, it just could mean we need XXX more dollars of support from funders to MOOSE/MFEM to make the port happen

[tzanio]

good questions @lindsayad 😁

how easy is it for downstream applications to program nonlinear weak forms? Perusing some of the issues, it seems like it can be non-trivial but I could be reading wrong and/or the issues I’ve looked at are fairly old (I can link to these when I’m on my comp)

Different applications do this differently and we have several approaches e.g. in the DPG miniapps, the darcy-hdg-dev branch and the work on dFEM (ping: @psocratis, @najlkin, @jandrej). We can do better and have been discussing providing a simpler/general interface for that.

What is the status of enabling contact methods? This is an important capability for our DOE NE program in which mechanical and thermal contact are important physical features for many of the advanced reactor concepts we are modeling

There is support for various constraints solvers and example of integration with the Tribol library.

[lindsayad]

Starting a different sub-thread for a couple different questions. What would you say is your most used matrix assembly level? For partial assembly, what is the most commonly used backend? I would guess native. Do many folks use the libCEED backend?

[pazner]

I think many users still use the "legacy" assembly level because it supports all of the integrators and most general configurations. For high-order/high-performance/GPU-based applications, partial assembly is the most commonly used. GPU-accelerated full assembly is used when a matrix is absolutely required, but it is not as well-suited for GPU performance as partial assembly.

The native backend is likely the most frequently used, but libCEED (with the code generation backends) does provide higher performance.

[lindsayad]

Do you have any data about the relative performance difference on GPU between the native and libCEED backends? Just trying to have a ballpark idea, like 10%, 2x, etc.

[pazner]

Our recent paper includes some performance comparisons (arxiv version here), see for example Figure 1. Note that these are benchmarks mostly concerning operator evaluation, which itself will be a fraction of total runtime, so the full application speedup will be less than the speedup for the benchmark problems.

[lindsayad]

Great, thanks @pazner