New Compositional Staggered

mentioned in #1115 (closed)

Implementation and ported tests addressed in !2986 (merged) .

New Analytical solution and convergence test implemented in !3044 . Also implemented for old staggered in !3561 .

Troubleshooting branch: feature/misc_navierstokesnc .

Using this issue to collect all of the ideas and progress we have made (the MRs are not organized for this)

changed milestone to %3.6

added Failing Test Feature Request Freeflow Tests labels

First Idea: order of operations (@Kilian listed in !2986 (merged))

Order of operations error (multiplication) See https://stackoverflow.com/questions/48088766/c-double-multiplication-have-different-result-when-order-of-variables-is-chang

Mathis modified the neumann outflow function to try and match the previous implementation. When looking at the test_ff_stokes2c_advection test, the error reduced from 57% to 53% for the Velocity in the Y direction (the only failing variable).

Further checks? @mathis is there anyway you can post the changes you made for this check to the feature/misc_navierstokesnc branch?

Changes in the order of operations for boundary fluxes: 2996e6d6

Next Idea: Pressure/Viscosity (kilian/Mathis/Ned in !2986 (merged))

Non-zero derivatives of a face Dof momentum balance w.r.t. the lateral cell's pressures. This will have an effect on the viscosity, and therefore the shear stress.

Mathis implemented a constant viscosity not effected by the pressure, which does not seem to change the solution. @mathis, can you add an example of this somewhere(misc branch) too?

The introduction of a fake fluid system was then tested, and when the solutions from both implementations are compared with this fluid system, they pass. 094c5b71

Volumevariables return a constant viscosity (and molar density): 4df0cbaf

Base Epsilon:

With the previous BaseEpsilon of 1e-8 the maxwell-stefan test did not converge (singular matrix) and failed. With a BaseEpsilon of 1e-4 it runs and passes.

Zero-Thresholds: A few of the tests use zero-thresholds (diffusion tests, densitydrivenflow) in their cmake definition.

Idea: @heck's density driven flow in a column issue.

Katharina implemented a density driven flow in a coulumn to look at fingering. There are issues in this test with the internal dirichlet calls 2021a892

Next Idea: Analytical Solution

To test if everything is implemented correctly, we modified the SinCos Navierstokes test to include a solution for the component transport. This is done in !3044. Although the convergence order is 2, the solution for middle-resolved grids does not look good, and has oscillations. This uses an upwind weight of 0.5.

When using an upwind weight of 1, the solution remains incorrect, but without oscillations. A convergence order of 2 is not reached.

Next Idea: Read in old velocity

Mathis developed a check where the old velocity is read into the new staggered, and the transport is compared. 7c52c46c

@mathis, what did you find here? Did @martins also try this?

The translation of the boundary conditions was a bit troublesome but the transported quantities are in agreement with the solution from the old staggered. Instead there is a large error in the pressure (deltaP = p - 1.1e5) which can be reduced to a 7% difference by using internal Dirichlet constraints to correct the pressure an inlet and outlet.

assigned to @nedc

changed milestone to %3.7

changed milestone to %3.8

changed the description

The analytical tests introduced in !3044 and !3561 produce matching and good results. The transport can be quite sensitive to small errors in the velocity field (good results when using the analytical velocity for advection) but the multicomponent aspect seems to work fine.

We want to temporarily include the implementation for the old staggered discretization to show the good agreement between the two when porting the multicomponent tests.

The remaining tests (advective channel and density driven flow) don't pass. While the channel test appears quite good and a new reference solution may be justified, the test with density driven flow has some larger errors in the velocity field that have to be investigated. Possible sources of error to be looked at are compressibility, gravity and boundary conditions.

Next steps:

• Rerun channel test with a compressible fluidsystem to see how much compressibility contributes to the error. @mathis
• Add gravity terms to the analytical tests to see if it introduces new discrepancies. @nedc
• Try using a custom compressible fluidsystem (with simple rho(p) relation) in the analytical test?
• Use correct interpolation of quantities instead of arithmetic mean of neighboring values.
• Rebase the analytical test @nedc
• Try out density driven flow with density varying with temperature instead of component concentrations. @mathis

Running the 2d channel test with compressible fluids (1pLiquid<,H2O>, 1pGas<,Air>) shows good agreement between old and new staggered implementations. Running the test with air and a higher inlet velocity gives maximum discrepancies of 1e-9 (abs) and 1e-11 (rel).

@nedc, @mathis Shouldn't there be an if useMoles. here https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/freeflow/compositional/staggered/fluxvariables.hh#L92?

I'm not sure if I get your point. Isn't the flux vector already getting filled according to ùseMoles, and this last bit only accumulates the vector if needed?

yes, but it should always accumulate the mass balance no? Regardless of useMoles. Now it seems to me that we make a total mole balance if useMoles==true

I think the comment is just misleading, the localresidual also respects useMoles for the total conservation equation localresidual.hh. Is that incorrect or the comment wrong?

you need to know which one it is to set the correct boundary conditions. I think the diffusive terms only cancel in the total mass balance (reference system mass). Mass balance also seems to be the natural choice when you think about (Navier-)Stokes. (So think the comment is right.)

mentioned in issue #1304 (closed)

closed