i.e. give up after 10 instead of 15 Newton iterations. since this now
also causes the CNV convergence criterion to be ignored after 8
instead of after 13 Newton iterations, and because CNV stagnation
seems to be the cause for the vast majority of the failures, it does
not lead to worse results or more time step chopping on Norne but
causes fewer wasted iterations.
the performance summary at the end of a Norne run which are printed by
`flow_ebos` now looks like this on my machine:
```
Total time (seconds): 773.757
Solver time (seconds): 753.349
Assembly time (seconds): 377.218 (Failed: 23.537; 6.23965%)
Linear solve time (seconds): 352.022 (Failed: 23.2757; 6.61201%)
Update time (seconds): 16.3658 (Failed: 1.13149; 6.91375%)
Output write time (seconds): 22.5991
Overall Well Iterations: 870 (Failed: 35; 4.02299%)
Overall Linearizations: 2098 (Failed: 136; 6.48236%)
Overall Newton Iterations: 1756 (Failed: 136; 7.74487%)
Overall Linear Iterations: 26572 (Failed: 1786; 6.72136%)
```
for the flow_legacy family, nothing changes.
the problem here is that some types used as the `BVector` template
parameters return signed integers for the `size()` method, others
return unsigned ones.
this code mostly used the Eigen vectors as arrays anyway, so let's use
`std::vector`.
also, this patch only "mostly eliminates" Eigen from from these parts
of the code because the source files of the VFP code still use
AutoDiffBlock; Unfortunately this cannot easily be changed because
`flow_legacy` depends on these methods. (`flow_ebos` does not use the
incriminating methods.)
Let the simulator re-assemble and re-calculate the residuls for the case
when the simultor is converged but it was forced to take one more
iteration due to iteration < minIter().
- restrict pressure changes. Set default to 1.0 (this also effects flow)
- change default number of linear iterations to 150
- tell stabilized newton the residual occilates even if it occilates in
only one phase (this also effects flow)
- avoid problems realated to division on small numbers
Tested on SPE9, norne and Model 2 with significant improvments.
* remotes/totto82/frankenstein_mod:
Fix seg-fault for cases without wells
Some micro performance improvments and cleaning
Add THP support in the denseAD well model
Only solve the linear system when it is not converged.
Revert changes to NewtonIterationBlackoilInterleaved.cpp
add and use class wellModelMatrixAdapter
Remove unused code and remove Eigen vectors
New updateState
Some cleaning and small changes
almost all of them were caused by recent changes in the master
branch:
- there were methods added which depend on the types `V` and
`DataBlock`. these do not make much sense in the context of the
frankenstein simulator. Also, these types are defined globally for the
whole Opm namespace in `BlackoilModelBase_impl.hpp` (which should be
prosecuted as a fellony IMO)! Besides this, their names are useless;
'V' is the letter which comes after `U` in the alphabet and when it
comes to computers basically everything can be seen as a chunk of data
(i.e., a `DataBlock`).
- it seems like the new and shiny dense-AD based well model was never
compiled with assertations enabled, at least some asserts referenced
non-existing variables.
- the recent output-related API changes were pretty unfortunate
because they had the effect of tying the (sub-optimal, IMO) internal
structure of the model even closer to the output code: as far as I can
see, `rq` does only make sense if the model works *exactly* like
BlackoilModelBase and friends. (for flow_ebos, this could be
replicated, but first it would be another unnecessary conversion step
and second, most of the quantities in `rq` are of type `ADB` and much
of the "frankenstein" excercise is devoted to getting rid of these.) I
thus reverted back to an old version of the output code and created a
`frankenstein` branch in my personal `opm-output` github fork.
-- a new updateState is implemented based on dune vectors
-- the old is kept for comparision in this PR
-- the updateState is not identical.
Tested on spe1, spe9 and norne and it improves the convergence compares
to the old one.
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.)
while the printed number of "Non linear iterations" was correct in a
strict sense, it was very confusing if one was working on the
linearization code because the last Newton iteration of each time step
was linearized but not solved for (and the solution was thus not
updated hence it does not count as a "non linear iteration"). This
makes sense for large problems were the total runtime is completely
dominated by the performance of the linear solver, but smaller
problems exhibit the opposite behavior (i.e., for them, runtime is
typically dominated by the linearization proceedure), so one is more
interested in the number of linearizations, not the number of linear
solves.
models may need a more detailed picture of where they are in the
simulation. Note that since the timer objects are available at every
call site, this is also not a very deep change.
This means that details such as calling assemble(), solveJacobianSystem(),
updateState() etc. are now left to the model class. This will make it easier
to create new model classes with different behaviour (such as sequential models).