`flow_ebos` should be now capable of doing everything that
`flow_legacy` can and recently all testing seems to have been centered
on `flow_ebos`. note that `flow_ebos` does not yet support some more
advanced/exotic features like MPI, solvents, polymer, etc., but
neither does the plain `flow_legacy` binary. until `flow_ebos`
supports these features, the specialized simulators thus continue to
use the legacy code paths.
* origin/master:
Do not throw for unrecognized file when merging log files.
Do not populate cellData but issue a warning in parallel.
Removed ternary operator in inline initialization.
Correctly mark transfer of ownership for ouptut writer
Indent nested #if
Remove Solution.sdc assignment
Cater variable name change in BCRSMatrix of DUNE 2.5
Fix using local active cells for writing eclipse files in parallel.
add restart test for SPE1CASE2_ACTNUM
rename the 'flow' binary to 'flow_legacy' and set a symbolic link
Added ctest for restart files
it uses ebos for linearization of the mass balance equations and the
current flow code from opm-simulators for all the rest. currently, the
results match the ones from plain `flow` for SPE1, SPE9 and Norne, but
performance is not optimal: on SPE9, converting from and to the legacy
data structures takes about a third of the time to do the actual mass
balance assembly. nevertheless `flow_ebos` is almost as fast as plain
`flow` for SPE9. (for Norne `flow_ebos` is about 15% slower, even
though the results match quite closely. the reason for this is that it
requires more iterations for some reason.)
This commit adds sequential solvers, including a simulator variant
using them (flow_sequential.cpp) with an integration test (running
SPE1, same as for fully implicit).
The sequential code is capable of running several (but not all) test
cases without tuning or special parameters, but reducing ds_max a bit
(from default 0.2 to say 0.1) helps with transport solver
convergence. The Norne model runs fine (esp. with a little tuning). A
parameter iterate_to_fully_implicit (defaults to false) is available,
when set the simulator will iterate with alternating pressure and
transport solves towards the fully implicit solution. Although that
takes a lot extra time it serves as a correctness check.
Performance is not competitive with fully implicit at this point:
essentially both the pressure and transport models inherit the fully
implicit model and do a lot of double (or triple) work. The point has
been to establish a proof of concept and baseline for further
experiments, without disturbing the base model too much (or at all, if
possible).
Changes to existing code has been minimized by merging most such
changes as smaller PRs already, the only remaining such change is to
NewtonIterationBlackoilInterleaved. Admittedly, that code (to solve
the pressure system with AMG) is not ideal because it duplicates
similar code in CPRPreconditioner.hpp and is not parallel. I propose
to address this later by refactoring the "solve elliptic system" code
from CPRPreconditioner into a separate class that can be used also
from here
That's the convention used elsewhere in the build system and we
should honour that convention. While here, remove the assignment to
PROGRAM_SOURCE_FILES because that variable is no longer referenced
once we start to run the hooks.
Currently this bootstrapper only finds the macros that are located
in the cmake/ tree in this project. Projects that don't carry their
own build system can specify search locations here.
Introduce a main build file which uses modules in the cmake/ directory
for most of its bulk work, which agains retrieve information from files
in the root of the source tree (dune.module, CMakeLists_files.cmake) to
get information about the project.
Thus, the cmake/ directory is shared between all the projects down to
the last bit; only project-specific customizations go into the main file
in form of _hook macros (which are called in specific places).
This let you specify a bunch of directory names on the command line
to *all* packages, without getting annoying warnings that they are
defined but not used.
Fall back to Eigen's BiCGSTAB solver if UMFPACK is not available. The
BiCGSTAB is built into Eigen and consequently always available when
Eigen is found.
Not all systems provide UMFPACK so even if Eigen provides the required
bindings, we should not assume that the underlying library and/or
headers are available. Currently, only examples/sim_simple.cpp uses
UMFPACK unconditionally, so the simplest solution is to exclude that
example unless UMFPACK is available.
