Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finite volume interface kernels for porosity jumps, contact, .. #17087

Closed
GiudGiud opened this issue Feb 21, 2021 · 7 comments · Fixed by #17449
Closed

Finite volume interface kernels for porosity jumps, contact, .. #17087

GiudGiud opened this issue Feb 21, 2021 · 7 comments · Fixed by #17449
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@GiudGiud
Copy link
Contributor

Reason

For many different physics, we do not want to resolve sharp transitions at interfaces with the mesh, and would rather introduce a discontinuity that captures this transition.

Design

A kernel that only contributes to the residual on faces that belong to an interface.
There will probably be many similarities to FVFluxKernels, which only act on (all element's) faces.

Impact

Huge boost to finite volume modeling of nuclear reactors

@GiudGiud GiudGiud added T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. labels Feb 21, 2021
@GiudGiud GiudGiud added this to To do in FY 21 NEAMS TH Pronghorn via automation Feb 21, 2021
@lindsayad
Copy link
Member

@GiudGiud the way I handled this for CNSFV was to apply the divergence theorem to the epsilon * grad_pressure term. The resulting epsilon*pressure should be much smoother so I just use the same epsilon-pressure FVFluxKernel across the whole domain with no special treatment at porosity jump interfaces.

@lindsayad
Copy link
Member

Although the math is not quite right on that, is it...

@lindsayad
Copy link
Member

Actually the math is good as long as epsilon doesn't have a gradient within a cell. If it does, then you would need an additional term:

-\int Ip * \nabla \epsilon dV

The problem is in implementation...we know that Green-Gauss computations of either grad_p or grad_eps will be problematic near interfaces where both p and eps are discontinuous

@GiudGiud
Copy link
Contributor Author

GiudGiud commented Mar 4, 2021

What do you do at boundaries then? Is that kernel executed on boundaries?

I think Paolo wanted to have the option to define a form loss coefficient too.

We dont need grad_eps for this term?

@lindsayad
Copy link
Member

lindsayad commented Mar 4, 2021

But at least in the case of epsilon it will almost always be constant within cells or at worst have a user-prescribed function within a cell whose gradient is clearly defined...e.g. we wouldn't have to do Green-Gauss with information from discontinuous faces

@lindsayad
Copy link
Member

What do you do at boundaries then? Is that kernel executed on boundaries?

Yes in general this FVFluxKernel or rather a FVFluxBC relative must be executed on boundaries.

I think Paolo wanted to have the option to define a form loss coefficient too.

In this case we would want a FVInterfaceKernel for sure

We dont need grad_eps for this term?

Which term?

@GiudGiud
Copy link
Contributor Author

GiudGiud commented Mar 4, 2021

The momentum pressure term.
EDIT: ok it is in the extra term you would need to add

FY 21 NEAMS TH Pronghorn automation moved this from To do to Done Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Development

Successfully merging a pull request may close this issue.

3 participants