These versions are inspired by the ones used in SuperLU and the enums
to choose them have simuilar names, but without leading S (MILU_1-MILU_3).
The following variants are supported (chosen by the enum MILU_VARIANT):
ILU: plain ILU
MILU_1: lump diagonal with dropped row entries.
MILU_2: lump diagonal with the sum of the absolute values of the dropped row
entries.
MILU_3: if diagonal is positive add sum of dropped row entrires. Otherwise substract them.
MILU_4: if diagonal is positive add sum of dropped row entrires. Otherwise do nothing
These versions are inspired by the ones used in SuperLU and the enums
to choose them have simuilar names, but without leading S (MILU_1-MILU_3).
The following variants are supported (chosen by the enum MILU_VARIANT):
ILU: plain ILU
MILU_1: lump diagonal with dropped row entries.
MILU_2: lump diagonal with the sum of the absolute values of the dropped row
entries.
MILU_3: if diagonal is positive add sum of dropped row entrires. Otherwise substract them.
MILU_4: if diagonal is positive add sum of dropped row entrires. Otherwise do nothing
We did add the dropped matrix blocks to the diagonal blocks,
but this is not MILU where oone only modifies the diagonal.
With this patch we fix this behaviour and now only modify the
diagonal of the diagonal block.
Using the parameter ilu_milu=true|false (default=false) the user can now choose
to use the modified ILU0 decomposition. If selected values will
not be dropped for nonzero entries but added to the diagonal of U.
This approach will result in A*e = L*U*e for vector e with all entries
beging 1.
this is necessiated by the replacement of `std::shared_ptr` by raw
pointers for the eWoms auxiliary equation infrastructure. Note that by
default `flow` will *not* create an auxiliary equation module because
it modifies the operator that is used by the linear solver instead.
this was forgotten when moving the output writing code into the ebos
core. (this does not really matter for most people because
asynchronous output is wanted anyway and it was unconditionally
enabled.)
these objects are only used by flow_legacy, so not having to deal with
them anymore lets non-legacy flow avoid to jump through a lot of hoops
for the sake of having a common API.
this required a fork of the NonlinearSolver and AdaptiveTimeStepping
classes. this is not a problem because the original classes would get
pruned to look like the new ones once flow_legacy gets moved out of
the opm-simulators module.
