Add strongly-imposed H(div) Dirichlet BCs

[nmnobre]

Hi Alex,

The idea here is to try to strongly impose Dirichlet boundary conditions on problems in H(div) because nobody likes penalties that much.

It's our understanding the only support for strong boundary conditions is via the nodal boundary conditions infrastructure which cycles through boundary nodes, and therefore never has any concept of elements, or their sides, and thus no means for integration. So, here, we instead tried to use the integrated boundary conditions infrastructure to recover the ability to integrate but, of course, this poses some difficulties when the time comes to override the required Jacobian and residual entries.

The approach we took applies a boolean mask on the current element's Jacobian and residual, thereby erasing any entries we wish to override while preserving the entries we wish to keep corresponding to dofs in the bulk of the domain. This all assumes the assembly will go through ThreadedElementLoopBase<RangeType>::operator() and thus that any boundary contributions are computed after the bulk element contributions.

Number of (linear) iterations for the tests prescribed by coupled_electrostatics.i:

Element type	Weak (penalty) BCs	Strong BCs
HEX27	83	20
TET14	1509	1177
TRI6/7	328	328
QUAD8/9	22	9

Missing:

• documentation
• an implementation for H(curl)/Nédélec one

Possible improvements:

• element-wise multiplication for libMesh's DenseMatrix and DenseVector to hide it from MOOSE's code
• ~can I omit some postprocessors/variables from a CSVDiff (or a .csv output) to avoid unnecessary redundancy in the gold files?~ Done, thanks @GiudGiud!

Cheers, -Nuno

[moosebuild]

Job Documentation on 64ec1e0 wanted to post the following:

View the site here

This comment will be updated on new commits.

[moosebuild]

Job Coverage on 64ec1e0 wanted to post the following:

Framework coverage

	c36c4a	#26595 64ec1e
	Total	Total	+/-	New
Rate	85.06%	85.06%	+0.00%	90.91%
Hits	104220	104280	+60	60
Misses	18308	18314	+6	6

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[nmnobre]

What you have here is an elegant idea. However, there are APIs in the tagging interface that allow bypassing the local residual and Jacobian data structures so that a residual object can pass its residuals/Jacobians directly to Assembly;

Yeah, we noticed those. We had a solution intercepting cached entries, but it was so ugly we gave up.

A more bullet-proof solution would be to think about how we can generalize what we do for "nodal" boundary conditions for non-nodal boundary dofs.

Funny you mention it!, because we actually tried that too: https://github.com/idaholab/moose/compare/next...farscape-project:moose:dirichlet_nodal. Please ignore the print statements. The important bit is that by skipping all the is-this-a-nodal-variable checks on the example RT0 problem, MOOSE actually overrides the Jacobian and residual entries that you expect (those on boundary faces -- after all, all DoFs lie on a node). The problem is once you're there, you have no way of integrating. As far as I know, there's no way of getting an edge/face from a node, is there?

[lindsayad]

You don't necessarily need JxW right? That will only influence scaling of the constraint. But you definitely need the _normals. So yes we wouldn't be able to use the nodal loop to apply these constraints

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[lindsayad]

should we keep this open @nmnobre?

[nmnobre]

I think I'd very much like to come back to this yes. I'm guessing the bot will shut up if I force push?

[GiudGiud]

you just need to comment to fend the bot away