Give examples of Darcy/Forchheimer coeff calculation

[lindsayad]

@fdkong

[lindsayad]

@GiudGiud and @snschune as the Ergun equation is on Wikipedia, I feel like it is an easy candidate for migration from Pronghorn into NS (at least the functor version). This would help I think with porous users getting a feel and understanding of how the friction terms are computed in more realistic scenarios (e.g. not just having tests where we explicitly supply cL and cQ in the input file).

[moosebuild]

Job Documentation on 688785e wanted to post the following:

View the site here

This comment will be updated on new commits.

[fdkong]

Thanks. The example does not consider negative sign: "-f_i"

[lindsayad]

@fdkong in the newest commit I discuss the negative sign

[GiudGiud]

I agree. i would rather we merge my future fix of the friction system first but we can do either

[lindsayad]

yea we can wait on the Ergun migration until your friction kernel change. Have we found at least one literature source that uses velocity component instead of velocity magnitude for Forchheimer? I feel like we need at least one reference before making that particular change. The Wikipedia article I link to here in this PR for the Ergun equation uses velocity magnitude

[fdkong]

We might implement something like

https://openfoamwiki.net/index.php/DarcyForchheimer

[GiudGiud]

that is yet another formulation? ignoring the other factors tr(U dot I) U is tr( (ux 0 0, 0 uy 0, 0 0 uz) ) U = ( ux + uy + uz ) * U currently we have |U| U btw

This report on page 4 roughly agrees, says | ux + uy + uz | * U or more likely ( | ux |+ | uy | + | uz | * U) http://www.tfd.chalmers.se/~hani/kurser/OS_CFD_2008/HaukurElvarHafsteinsson/haukurReport.pdf

[lindsayad]

So should I close this? I think the Ergun example is really beneficial and should be included in the documentation. But it could wait for the modifications that @GiudGiud is planning to do to the kernel.

[GiudGiud]

no need to close it. I ll fix up the coefficient everywhere, then will adjust this PR

[fdkong]

I would think it would be better to get the "straightforward" method implemented.

[fdkong]

It seems actually fine to get this merged. This doc made things a lot better already

[GiudGiud]

will need a rebase to remove the merge commit.

[snschune]

I thought you would move the Ergun correlation from Pronghorn to MOOSE? Is this just about giving an example for a Darcy/Forchheimer relationship?

Also, is there the ability to specify a quadratic pressure drop just in MOOSE without much work from the user? Something like dp = K * |v|v?

[lindsayad]

I thought you would move the Ergun correlation from Pronghorn to MOOSE?

We will but I think @GiudGiud was planning to do this around the time we finished refactoring the actual friction kernel code

Is this just about giving an example for a Darcy/Forchheimer relationship?

Correct

[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.

[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.

[GiudGiud]

I ll get to reworking the friction factors etc

[veeshy]

Neat, any update on getting this example out / the rework alluded to? I haven't touched the functor system and was hoping for a leg up on implanting a friction factor

edit: for what it's worth, I found ADCoupledVelocityMaterial to be an excellent starting point for adding a functor material.

[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]

This is still something we should do

[GiudGiud]

I agree Should it come before unused parameters for meshing though haha

My reason for stalling this was that we should fix the definition of Darcy vs Forchheimer coefficients first

[lindsayad]

i would rather we merge my future fix of the friction system first but we can do either

Should we recap what that fix is? I've lost track over time

[GiudGiud]

Have the commonly accepted definition of Forchheimer coefs, not multiplied by v like we do

[lindsayad]

v multiplication has to happen; it's just a question of where in the code right?

[GiudGiud]

Yes exactly

[lindsayad]

And we currently do the speed multiplication in the material, and we want to move it to the kernel ... right?

[lindsayad]

E.g. like our INSFVMomentumFriction implementation, and not like the PINSFVMomentumFriction implementation

[GiudGiud]

yes

[GiudGiud]

though there might be additional details. And Pgh will definitely need a patch