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
FV: materials initialized to FE quadrature in FV contexts #15194
Labels
C: Framework
C: Modules/Navier Stokes
Tickets pertaining to the navier_stokes module
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: defect
An anomaly, which is anything that deviates from expectations.
Projects
Comments
rwcarlsen
added
C: Framework
T: defect
An anomaly, which is anything that deviates from expectations.
P: normal
A defect affecting operation with a low possibility of significantly affects.
labels
May 1, 2020
lindsayad
added a commit
to lindsayad/moose
that referenced
this issue
Dec 4, 2020
As pointed out in idaholab#15194, we have historically not had the correct physical location for quadrature points when computing either `FVElementalKernels` or `FVFluxKernels/FVFluxBCs`. This commit computes the correct physical quadrature point locations for the FV flux loop, so we are fixing half the problem outlined in idaholab#15194
I ran into this when using wall distances in pronghorn materials, which uses _q_point. It will indeed make me happier |
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 4, 2020
…at boundary by FVDiffusion kernel, idaholab#15194
4 tasks
lindsayad
pushed a commit
to lindsayad/moose
that referenced
this issue
Dec 9, 2020
…at boundary by FVDiffusion kernel, idaholab#15194
jain651
pushed a commit
to jain651/moose
that referenced
this issue
Apr 19, 2021
As pointed out in idaholab#15194, we have historically not had the correct physical location for quadrature points when computing either `FVElementalKernels` or `FVFluxKernels/FVFluxBCs`. This commit computes the correct physical quadrature point locations for the FV flux loop, so we are fixing half the problem outlined in idaholab#15194
jain651
pushed a commit
to jain651/moose
that referenced
this issue
Apr 19, 2021
…at boundary by FVDiffusion kernel, idaholab#15194
lindsayad
added
C: Modules/Navier Stokes
Tickets pertaining to the navier_stokes module
and removed
C: Finite Volume
labels
Oct 12, 2021
We now use functor material properties that we evaluate with an element argument for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C: Framework
C: Modules/Navier Stokes
Tickets pertaining to the navier_stokes module
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: defect
An anomaly, which is anything that deviates from expectations.
Bug Description
Currently in FV, material properties are initialized/reinit'd to the normal FE quadrature points even in the FV flux loop and for FV elemental kernels. So material properties used by FV objects that may depend on coordinate/geometric information (e.g. a parsed material depending on x,y,z) will produce incorrect values using only the zeroth-index qp geometric information (since FV only uses the 0-index qp).
Steps to Reproduce
Create an FV kernel that depends on a parsed material with x,y,z dependence. See that your solution is wrong.
Impact
This will not require any API breaking changes to fix. Just internal moose stuff. Fixing it will only make people happier.
The text was updated successfully, but these errors were encountered: