IMO the term "vanguard" expresses better what these classes are
supposed to do: level the ground for the cavalry. Normally this simply
means to create and distribute a grid object, but it can become quite
a bit more complicated, as exemplified by the vanguard classes of
ebos..
The new eclwriter output and restart using the eclIO from opm-output
All tests in opm-simulator pass and
MPI restart works.
Standard initialization is done prior to restart in order
to compute correct initial thpressure values. This is not
necessary if thpressures are written to the restart file
TODO: Some trivial fields are written out in order mimic legacy code,
this should be cleaned up
TODO: Output of wells, FIP, NNC is still done in opm-simulators.
This should be moved later.
Judging from ParallelDebugOutput.hh this is what is should be.
Before this commit it was empty as it had space reserved but never
any entries pushed (they were inserted with operator[]).
This reverts commit dde79daf4ec2004148a58250c4c8af5390251689.
Judging from ParallelDebugOutput.hh this should not be a map from element
index to interior element index, but an a list of indices of all interior
elements. Therefore we need to reserve and later on push_back.
This reverts commit 09db2fd412abe4b8a2f52274bcc0041e4b20a94d.
Judging from ParallelDebugOutput.hh this should not be a map from element
index to interior element index, but an a list of indices of all interior
elements
Previously distributedCartesianIndex was resized and afterwards all
entries were added with push_back. Therefore the array was twice as
big as expected and contained wrong values in the front.
With this commit we insert the values using random access. Thus the
size is as expeceted and the index of the entries do not depend on the
order of the grid traversal.
While it may not produce memory errors it is semantically wrong to insert
entries with random acces into a vector that has reserved enough memory to
hold the values but still has size 0.
