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

FV: materials initialized to FE quadrature in FV contexts #15194

Closed
rwcarlsen opened this issue May 1, 2020 · 2 comments
Closed

FV: materials initialized to FE quadrature in FV contexts #15194

rwcarlsen opened this issue May 1, 2020 · 2 comments
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.

Comments

@rwcarlsen
Copy link
Contributor

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.

@rwcarlsen 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
@lindsayad lindsayad moved this from To do to In progress in FY 21 NEAMS TH Pronghorn Dec 4, 2020
@GiudGiud
Copy link
Contributor

GiudGiud commented Dec 4, 2020

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
lindsayad pushed a commit to lindsayad/moose that referenced this issue Dec 9, 2020
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
@lindsayad lindsayad added C: Modules/Navier Stokes Tickets pertaining to the navier_stokes module and removed C: Finite Volume labels Oct 12, 2021
@lindsayad
Copy link
Member

We now use functor material properties that we evaluate with an element argument for FVElementalKernels or with a face-info argument for FVFluxKernels. Consequently this issue is no longer relevant. Considering closed by #18395

FY 21 NEAMS TH Pronghorn automation moved this from In progress to Done Nov 24, 2021
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.
Development

No branches or pull requests

3 participants