when there is new control keywords enter, the combination of control /
constraints change. Under this kind of situation, copying the control
index does not mean you copy the same types of control.
Using the control index from the previous WellState for many situation
is a good practice, while it also risks copying a random and rather bad
choice. It is a major problem when we have VFP, VFP can have very
damaging values for certain situation to show it is not desirable to
be in this kind of situation.
`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.
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.
or are these called integration tests? anyway, these are the tests
which use the decks from opm-data. This should put flow_ebos testing
on the same level as flow_legacy.
First, the stepReport variable was not used with adaptive timestepping.
Second, even when properly updating stepReport, solver_time is still 0.
It just happens that lots of other timing variables are updated, but not
solver_time (nor total_time, pressure_time and transport_time). Simplest
way to handle is to just report the solver_timer seconds (which are still added
to the "full sim report"'s solver_time).
Previously the substep summary reports were cumulative, misleading the user.
Also, made output a little more compact and readable, ensuring numbers line up
unless unusually many digits are needed for times and iteration counts.
Motivated by
- proliferation of identical code
- need to avoid strange behaviour with "." directory on some boost versions
- potenial for further refactoring to avoid boost entirely
These are not aware whether they are parallel or not. Therefore
the user should only specify a verbose verbosity only on one rank.
With this commit we do this on the process responsible for terminal
output.
