Add a Physics for linear FV + mixture model
Requires #29177 and maybe #29516 to try out transients (or some other way to get a converged solution)
One difficulty is likely that the two phase equation needs to be an "active" scalar, not a passive one, and be solved inside the pressure-velocity-energy picard iteration. I added code for that. I ll revisit this PR once the prereqs are merged
Job Documentation, step Docs: sync website on 6d72f22 wanted to post the following:
View the site here
This comment will be updated on new commits.
Once the PR is ready, please consider adding a technical reviewer as per our suggested merge standards to NS. Thanks!
Job Coverage, step Generate coverage on 6d72f22 wanted to post the following:
Framework coverage
Mutiple base shas were found when retrieving head reports: 5e24328f05d447a9d705b332e2478ee9d1d69279 98f5d7bf5842f4cb14a1dc4be83983680b5c1024
Modules coverage
Navier stokes
| 5e2432 | #29614 6d72f2 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 85.24% | 85.28% | +0.04% | 87.46% | |
| Hits | 18785 | 19226 | +441 | 488 | |
| Misses | 3252 | 3318 | +66 | 70 | |
Full coverage reports
Reports
-
framework(FAILED) -
chemical_reactions -
combined -
contact -
electromagnetics -
external_petsc_solver -
fluid_properties -
fsi -
functional_expansion_tools -
geochemistry -
heat_transfer -
level_set -
misc -
navier_stokes -
optimization -
peridynamics -
phase_field -
porous_flow -
ray_tracing -
rdg -
reactor -
richards -
scalar_transport -
solid_mechanics -
solid_properties -
stochastic_tools -
subchannel -
thermal_hydraulics -
xfem
Warnings
-
navier_stokesnew line coverage rate 87.46% is less than the suggested 90.0%
This comment will be updated on new commits.
any preferred test case on this? It s only 1 model for mixture. no solidification or any refinement. and any volunteer for technical review? (once I clean up the tests etc, not now)
@tanoret I can try to reproduce the rayleigh-bernard convection input with Physics & linear FV. Is that enough ? Is there a particular flow test bed input you would like to see?
The results are not a great match for the two test cases between linear and nonlinear.
EDIT: fixed! Some differences in how we were doing friction & interpolation fixed, and gravity term fixed too
@tanoret or @MengnanLi91 can you please do the technical review / validation?
Can we merge this @tanoret, @MengnanLi91 ?
Can we merge this @tanoret, @MengnanLi91 ?
Maybe wait a bit? @tanoret mentioned he has something to change for the mixture model.
Agreement with nonlinear FV is quite good now with these changes
- extrapolated pressure at the inlet in linear FV
- pressure drop computation fix for the pressure face interpolation
Rebased on #30288 which should be merged first
@tanoret the linear FV. two phase mixture will now error with skewed meshes. This should address your concern.
BTW, I ran a few single phase cases on skewed meshes without skewness correction and got really bad results, which turned into really good results with skewness correction. Maybe the check I have here should just go in all our FV code as well to request skewness correction.
@grmnptr did you want to re-review this?
@grmnptr @tanoret last commit is a bug fix on gravity for the flow physics. We should make a decision on this PR so this bug fix makes it in regardless.
Good for me to merge once the test are passing. Thank you for the work @GiudGiud!
Edit: Sorry, could we please add at least one test using kernels? Currently this only use physics and this is not the main way in which our users currently interact with the models. Thank you for understanding
@grmnptr
That flux is lagged, while the advected quantity interpolation is treated implicitly. It feels like we have it backwards here.
That's out of necessity. Writing the linearization of the slip velocity is not easy. See WCNSFV2PSlipVelocityFunctorMaterial we would need to get the dfriction term/du (friction term could be from anything), dgrad_u/du etc.
Both terms are implicit here.
Traditionally, the advecting flux is interpolated with average/rc and the advected quantity uses coeff/(1-coeff).
The "velocity interp coeffs" here is only for the "trick" of multiplying by u/u_old. The face flux is: -face_rho_fd * uslipdotn * u_slip_vel_vec(_index);
face_rho_d is using the expected interpolation method. uslip is using the same functor material as used in nonlinear wcnsfv. There are quite a few terms there. There is possibly one term (advection) that could use RC interpolation, but we were not doing that for nonlinear wcnsfv
We could also try to lag the slip velocity (again the "trick" does not matter imo) since it's effectively the advecting velocity. But that would be different from the nonlinear WCNSFV implementation
That flux is lagged, while the advected quantity interpolation is treated implicitly.
for momentum we treat both implicitly I think. Since this is in the momentum equation we might be in line here?
Job Coverage, step Verify coverage on 6d72f22 wanted to post the following:
The following coverage requirement(s) failed:
- Failed to generate
frameworkcoverage rate (required: 81.0%)
Thanks for the reviews!