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
Some postprocessors need ghosting layers for FV #19534
Labels
C: Framework
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
GiudGiud
added
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
Dec 3, 2021
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 3, 2021
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing.
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 3, 2021
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing.
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 4, 2021
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 5, 2021
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420 Use interface diffusive flux instead of side to use both sides
GiudGiud
added a commit
to GiudGiud/moose
that referenced
this issue
Dec 5, 2021
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420 Use interface diffusive flux instead of side to use both sides regold
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: defect
An anomaly, which is anything that deviates from expectations.
Bug Description
SideDiffusiveFluxXXX for example.
Takes a gradient on a boundary, needs to ghost
Steps to Reproduce
Seg fault with 2 mpi ranks when using one of those on the middle of the domain
This only seg faults if you dont have kernels that provide the required ghosting.
For example if you are solving diffusion for that variable, then taking a diffusive flux is fine
Impact
bug
The text was updated successfully, but these errors were encountered: