Can you block restrict boundary conditions?

[Eilloo]

Hello all,

I am wondering if it is possible to block restrict a boundary condition - or indeed, if it makes any sense to?

The reason for doing this is related to #23484:

I am trying to implement the same conditions described by the CoupledPenaltyInterfaceDiffusion interface kernels, instead using custom BCs which inherit from IntegratedBC, and are manually applied to what would be variable and neighbour_variable if using an interface kernel.

I think my issue could be because I cannot differentiate between each side of the interface, and the neighbour_variable is defined on both sides.

I am concerned that without some kind of block restriction, I am not actually setting the element residuals on each side of the interface to be equal through my custom BCs, and the BC handling neighbour_variable is actually contributing to the element residuals on both sides of the boundary. If so, this would prevent the residuals from being equal, no longer implying the continuity of flux as described in the linked thread.

Is this a legitimate concern and if so, is there a way to block restrict boundary conditions so the contribution of neighbour_variable is only applied on one side?

Thanks!

[GiudGiud]

If the neighbour variable is only present on one side, the BC will only contribute to its "variable=" parameter so it will only contribute on one side

Why is the neighbor_variable defined on both sides?

A BC inside a variable's domain is not normal. I think you should look at interface kernels at this point

[lindsayad]

At first I was confused by why we are then taking the gradient; however, I now think that 'RealGradient' is simply a data type where we can store the appropriate vector of test functions, rather than calculating any gradient.

exactly correct

I am testing everything using the example flat channel input file, which gives me some confidence in the boundary conditions...
Given the above, where would you suggest I look for reasons that NEWTON does not converge, when PJFNK does?

Do you have a git branch I could pull and do some testing?

[Eilloo]

I've added the new kernels and input files to a new app in a git repo here:

https://github.com/Eilloo/FlatChannelFSI_VectorNS.git

Let me know if that doesn't work for any reason!

[lindsayad]

I tried compiling this with the devel branch of MOOSE and couldn't compile

[Eilloo]

Ah, sorry - my bad, it should work now!

[lindsayad]

I just pushed a commit. You had value() in your AD interface kernels. That blows away all the AD computations for the Jacobian. You should never use that function

[Eilloo]

Aaah, it's always something small - that's good to know, I'd misunderstood what value() does from the docs.
That has done the trick - thanks a lot for taking a look! :)

[lindsayad]

You're welcome!