this has recently been moved there. Since redundancy is considered to
be bad, switch eWoms to it.
I've tested this with Norne: No measureable difference, as expected.
for some reason the results have changed. (IMO, the new ones look more
correct in paraview.) The reason this was not discovered earlier is
that this test depends on the presence of dune-alugrid and the CI
infrastructure does not deal with this.
the reason is that cmake cannot file(COPY) them. this is probably due
to constraints of a crappy operating system that is made by a
microscopical and tender company which is based close to Seattle.
so far, the linker bailed out due to duplicate definitions of
variables if multiple compile units used the same type tag. This is
problematic if the sources are split into separate compile units and
that use the same type tag; in particular, this applies for
traditional libraries.
Due to various C++ peculiarities, this patch complicates the internal
implementation of the property system quite a bit, but given that the
usage of it (as well as the compile time) stay unchanged, I do not
consider this to be a big problem. Note that the introspection code is
particularly problematic because it needs static initializers that do
not cause the linker to choke in the case of multiple compile units.
Finally, to prevent future regressions, this patch adds a unit test
for the lens problem which uses multiple compile units. (This test is
called lens_immiscible_ecfv_ad_mcu and basically identical to the
existing lens_immiscible_ecfv_ad test and I thus think that it is
pretty unimaginative -- improvement proposals are welcome.)
there seems to be only a *very* limited amount of interest, the code
of the model is quite complex and there are currently no suitable
discretizations for free-flow equations in eWoms (i.e., the model
tends to be very unstable and oscillates a lot). Combined, all of this
makes maintaining this model a pain in the back, so let's remove it
some interest in these kinds of problems surfaces and until
appropriate discretizations -- like staggered grid methods -- are
available.
This works by having a "focus degree of freedom" during
linearization. When evaluating the local residual, all derivatives of
the residual/fluxes are with regard to the primary variables of that
DOF.
The two main offenders were the Forchheimer velocity model and the
model for the Stokes equations. To ensure that they continue to work,
the "powerinjection" and the "stokestest2c" problems are now both
compiled and tested with both, automatic differentiation and finite
differences, and the results of these tests is compared against the
same reference solution.
The majority of the time required to develop this patch was actually
required for testing: All tests compile and pass with debugging and
aggressive optimization flags with at least GCC 5, GCC 7 and clang
3.8, as well as Dune 2.3 and 2.4. Also, the results of flow_ebos stay
identical for Norne whilst the performance difference is below the
measurement noise on my machine. (the version with this patch applied
was actually about 1% faster.)
this belongs to the `tests/data` directory, not into the toplevel
`data` directory. Also, the input ART file for this has been renamed
to `fracture-raw.art` to avoid race conditions.
for the vertex-centered finite volume discretization, the relevant
position for calculating the gradient is *not* the position of the
center of the *sub*-control volume, but the center of the whole
control volume.
Since this patch changes the gradients of all VCFV simulations that
use twopoint gradients, quite a few new reference solutions are
required by this PR. I've looked at all of them manually and made sure
that they look reasonable. (The PR also includes a new reference
solution for the test for the adaptive finger problem -- which uses
ECFV -- but that's because the grid refinement seems to be quite
sensitive to the solution proceedure for that problem, not because
there's any difference in the solutions that can be noticed visually.)
note that all simulations that use element centered finite volume
discretization because there sub-control volumes are identical to full
control volumes. In particular, ebos -- and by extension `flow_ebos`
-- is unaffected because it does not even use that code.
the groundwater problem should be symmetric because it uses an
incompressible fluid, is a single phase problem and uses the
immiscible model. (i.e., there should never be a difference between
the upstream and the downstream cells.)
the main purpose of this commit is to have a test that uses a linear
solver wrapper which was generated by the internal
EWOMS_WRAP_ISTL_SOLVER macro.
this gets rid of the ugly red and green boxes around references. Note
that for some reason, hyperlinks do not seem to work anyway and that
using pdflatex directly does not work either :/
TeXLive 2016 complains about \it and \bf.
Also, this patch adds a simple bash script to create the handbook from
its LaTeX sources. Note that this script does *not* attempt to detect
if all prerequisites (in terms of binaries and LaTeX packages) are
properly available.
... and use the restarted GMRES solver in conjunction with a ILU-2
preconditioner for the water-air unit test.
I do not really recommend using these solvers because BiCGSTAB tends
to be 20% to 30% slower than our home-brewn implementation (this is
because the dune-istl solvers cannot use custom convergence criteria),
but dune-istl offers more choices than just BiCGStab and this
functionallity could be helpful when debugging issues related to
solving the linear systems of equations.
Note that regardless of how pedantic the interpretation of DUNE's
license is, there are no licensing issues with this code because we do
not distribute any files derived from DUNE anymore.
i.e., the solvers.hh file is removed. The main reason for this is that
it avoids having to distribute a file with a potentially incompatible
license (i.e., GPLv2 + template exception vs GPLv2+), but the
home-brewn bicgstab solver also seems to perform a tiny bit better.