idaholab
Finite Volume PorousFlow
This is the initial work to support FV in the PorousFlow module.
@loganharbour, would you mind taking a look at this when you get chance before I go too far down the rabbit hole. 😆 I think this was the minimum I could do to get a working FV test problem while having all of the current tests in PorousFlow still working.
Job Precheck on 0e2ea04 wanted to post the following:
Your code requires style changes.
A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:
curl -s https://mooseframework.inl.gov/docs/PRs/21172/clang_format/style.patch | git apply -v
Alternatively, with your repository up to date and in the top level of your repository:
git clang-format ed91e1d359fd3b10c258835ee1d38105a7fc8140
Hmm, gcc doesn't like this. It looks like I need lots of this->template's in the code.
Hmm, gcc doesn't like this. It looks like I need lots of
this->template's in the code.
Luckily not too many this->templates were required!
Job Documentation on 7e7ec29 wanted to post the following:
View the site here
This comment will be updated on new commits.
Job Coverage on 7e7ec29 wanted to post the following:
Framework coverage
| b9fd6b | #21172 7e7ec2 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 84.79% | 84.77% | -0.01% | 5.26% | |
| Hits | 83682 | 83683 | +1 | 1 | |
| Misses | 15012 | 15029 | +17 | 18 | |
Modules coverage
Porous flow
| b9fd6b | #21172 7e7ec2 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 96.44% | 96.52% | +0.08% | 98.40% | |
| Hits | 10519 | 10652 | +133 | 552 | |
| Misses | 388 | 384 | -4 | 9 | |
Full coverage reports
Reports
-
framework -
chemical_reactions -
combined -
contact -
electromagnetics -
external_petsc_solver -
fluid_properties -
fsi -
functional_expansion_tools -
geochemistry -
heat_conduction -
level_set -
misc -
navier_stokes -
optimization -
peridynamics -
phase_field -
porous_flow -
ray_tracing -
rdg -
reactor -
richards -
scalar_transport -
solid_properties -
stochastic_tools -
tensor_mechanics -
thermal_hydraulics -
xfem
Warnings
-
frameworknew line coverage rate 5.26% is less than the suggested 90.0%
This comment will be updated on new commits.
Hi, I noticed Ferret failed here but when I looked at CIVET, I saw that all tests passed. Anyone know why?
Hi, I noticed Ferret failed here but when I looked at CIVET, I saw that all tests passed. Anyone know why?
Unrelated issue. Should be good now.
@loganharbour, would you mind taking a look at this when you get chance before I go too far down the rabbit hole.
👍🏼 on my list.
Job Precheck on eeb4cdd wanted to post the following:
A change of the following file(s) triggered this check:
libmesh
The following file(s) are unchanged:
conda/mpich/conda_build_config.yaml conda/libmesh/meta.yaml
The libmesh submodule or configuration was changed but the conda build config was not
I've just realised that it doesn't seem like there is any way to find the documentation (https://mooseframework.inl.gov/docs/PRs/21172/site/automatic_differentiation/templated_objects.html) I wrote. It follows on from https://mooseframework.inl.gov/docs/PRs/21172/site/automatic_differentiation/ but I can't find out where this links from. It should possibly be listed in 'Application development'?
@cpgr the AD page is linked to from some of the systems using AD https://mooseframework.inl.gov/syntax/Kernels/ or https://mooseframework.inl.gov/syntax/Materials/ for example
@cpgr the AD page is linked to from some of the systems using AD https://mooseframework.inl.gov/syntax/Kernels/ or https://mooseframework.inl.gov/syntax/Materials/ for example
Thanks! I was wondering how anyone would find this.
@cpgr I was wondering if you looked at our porous Navier-Stokes slides at https://mooseframework.inl.gov/slides/index.html#/ whether you could tell me what the difference between that and the equations solved by the porous_flow module is? I'm hoping there is a difference haha, and if so we should think about documenting that somewhere so our users know where to go for what application/modeling-assumptions is relevant to them.
@cpgr I was wondering if you looked at our porous Navier-Stokes slides at https://mooseframework.inl.gov/slides/index.html#/ whether you could tell me what the difference between that and the equations solved by the
porous_flowmodule is? I'm hoping there is a difference haha, and if so we should think about documenting that somewhere so our users know where to go for what application/modeling-assumptions is relevant to them.
The governing equations for the porous_flow module are outlined here -https://mooseframework.inl.gov/modules/porous_flow/governing_equations.html
They are basically conservation of mass of a fluid component + Darcy's law.
I think the main difference would be that this module is set up for more classical reservoir engineering cases, and can model an arbitrary number of fluid phases (most common use case would be 2 I imagine - a gas phase and a liquid phase), but each phase can have an arbitrary number of fluid components (eg, the liquid can be water + salt + dissolved gas component etc).
The FV stuff here (which is basically an FV equivalent to the FE objects already in this module) is to make it much easier to model cases where there are discontinuities in one of the variables, such as gas saturation , due to the reservoir properties.
It's fun learning about this. A really dumb question that I haven't answered for myself yet: if you were to model a single phase single component problem, what would your nonlinear variable(s) be? Is it just the pressure?
I've been using this for a little while now and it all seems to be working.
The only part I'm not certain on is in Coupleable.C. I needed to template coupledDofValues to template all the porous flow materials, so added
template <>
const GenericVariableValue<false> &
Coupleable::coupledGenericDofValue<false>(const std::string & var_name, unsigned int comp) const
{
return coupledDofValues(var_name, comp);
}
template <>
const GenericVariableValue<true> &
Coupleable::coupledGenericDofValue<true>(const std::string & var_name, unsigned int comp) const
{
return adCoupledValue(var_name, comp);
}
but I'm not sure on the AD one.
Yea that's probably not quite right. The dof values should return all the degree of freedom values in the solution vector associated with a given element, whereas the coupled value api's return the finite element solution evaluated at the element quadrature points
I couldn't find an adCoupledDofValues method - before I try and make one can I check that I'm not missing anything?
@cpgr are you waiting for a review on this?
Yeah, but no rush. This was to check that what I have done so far is ok. I know that there is a lot of work to make it work with all of the exiting PorousFlow objects, I just don't have time until next month to keep going.
If you or @loganharbour could just take a quick look and let me know if there is anything that I am not doing right that would be great.
Sounds good. I ll add it to my list and I think @lindsayad will want to have a look as well since this is FV
I should have taken the fact that you marked it as ready for review as a cue haha
Something has obviously changed - the flux kernel I was using no longer works! Any hints you could give me?
Hmm I think with @grmnptr's recent changes to remove ghost cells this might have plunged your neighbor material property evaluations when you're on a boundary into oblivion. What I would suggest, if you're wiling to wait, is to let #22130 go in, and then I can come push a commit to your PR updating your flux kernel. Would that be ok? I know you've already waited a long time, so if you're eager to have this in, then I can probably come up with a patch now
Ok #22130 is in. Want the follow-on #23233 to get through and with those two I have a pretty good idea about where I want to take this. I don't think it'll be a massive re-write like I initially thought