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.
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.)
* 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.
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).
