in an iterative way. When VFP interpolation is performed, the bhp and
rates are coupled together. Some iteration will be required to get the
consistent bhp and well potential.
to pick the least strict bhp limits in the well controls. It is used to
calculate the well potential when there is no thp limits there.
If there is thp limits there, it will be used for further chosing of the
bhp value for well potential calculation.
other places should gurantee the control indices from the well_state and
well_controls struct are the same.
And also, since the first element in wellSolutions() depends on the type
of the control, this function is complete yet.
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.
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.
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.
