Create ZeroNormalGradient FVFluxBC

[lindsayad]

Reason

This would allow me to eliminate the override of adGradSln(const Elem * const elem) in INSFVVelocityVariable. More generally speaking, zero normal gradients are a desired condition for FV simulations for many different kinds of physics and variables. For instance @smharper wants it at flow boundary outlets for scalar field variables. Note that having a ZeroNormalGradient class has implementation implications beyond setting the flux value at zero normal gradient faces: it also would play a role in cell centroid gradient calculations (e.g. the current reason why I have the INSFVVelocityVariable::adGradSln(const Elem * const elem) override, which would in turn modify residuals for diffusion-type flux kernels on internal faces of boundary elements.

Design

A layer on top of FVFluxBC. This would not implement computeQpResidual, so a derived class would still have to do that. ZeroNormalGradient is meant most for communicating information to MooseVariableFV routines.

Impact

Allows transition of code currently in the navier_stokes module into the framework, and hopefully also allows users greater ability to implement the boundary conditions they want.

[lindsayad]

@GiudGiud

[GiudGiud]

So you delete the override in INSFVVelocityVariable but you move the same code to INSFVVariable? I feel like we're headed to the deletion of INSFVVelocityVariable, INSFVPressureVariable and INSFVEnergyVariable, unless they come in handy for changes in RC later?

This class would basically be for tagging BCs so that the adGradSln solves the right system, same as FullyDeveloppedFlowBCs?

How about NormalGradient so it can be set to non zero? Kind of like a general NeumannBC

[lindsayad]

This class would basically be for tagging BCs so that the adGradSln solves the right system, same as FullyDeveloppedFlowBCs?

Exactly.

So you delete the override in INSFVVelocityVariable but you move the same code to INSFVVariable?

ZeroNormalGradient or NormalGradient could live in the framework, so the current system in INSFVVelocityVariable::adGradSln could be moved all the way up to MooseVariableFV. Potentially then we could even remove the virtual tag for adGradSln.

I feel like we're headed to the deletion of INSFVVelocityVariable, INSFVPressureVariable and INSFVEnergyVariable, unless they come in handy for changes in RC later?

Yea, I don't think I would delete them for backward compatibility purposes and in case there are currently unforeseen needs for them in the future, but the idea would be to make them largely unnecessary (at least at present). I think a goal of mine would be to make INSFV operable with normal MooseVariableFVReals and relax some of the current error checking in INSFV object constructors.

How about NormalGradient so it can be set to non zero? Kind of like a general NeumannBC

I like this idea.

[GiudGiud]

So in INSFVVelocityVariable, turned into a general framework object: Eqn 1 is standard, it's just the Green-Gauss gradient Eqn 2 will need to be turned on, with the _two_term_boundary_expansion flag, same as now. INSFVVariables will take care of that Eqn 3 will be added in the presence of NormalGradient boundary conditions, which will inherited be triggered by FullyDeveloppedFlowBCs

[lindsayad]

Eqn 2 will need to be turned on, with the _two_term_boundary_expansion flag, same as now. INSFVVariables will take care of that

Or can be turned on via the input file, but yea.

Yes, you've captured exactly what I'm imagining