this resolves#469.
since the arguments brought forward in that issue equally apply to the
tests which produce VTK files, and the willingness to manually update
reference results for these is likely even smaller, the results
produced by the eWoms integration tests are simply not validated
anymore besides the fact that the produced files must be non-empty.
Note that this only applies to the default build system; the
alternative system still does -- and will continue to -- validate the
results.
this segfaulted due to a small pecularity of the compareECL
utility. thanks to [at]akva2 for pointing this out.
Also, this updates the reference solutions for this test in an attempt
to fix the jenkins complaint: The test seems to be quite sensitive to
the used compiler flags and Jenkins is not able to update the
reference solutions yet.
this allows the key names to be transformed, i.e.,
```
enable-vtk=true
```
is now also possible in parameter files whereas before only CamelCase
parameter names like
```
EnableVtk=true
```
were valid. besides this, any valid Windows INI file that does not use
parameter groups should be readable, i.e., semicolons are now also
treated as a comment indicator.
this is only relevant people who are masochistic enough to go beyond
`-Wall`. (note that at this warning level, there is plenty of noise from
Dune and other upstream dependencies.)
Use a mutex to ensures that only a single prints at the same
time. this should prevent garbled terminal output and thus makes the
it much easier to read. on the flipside, some race conditions may go
unnoticed.
this leads to crashes deeply inside libecl. My cursory hypotheses are
that this test makes the assumption that the output is written
synchronously (it tries to read back the results from disk
immediately) and/or that libecl is not threadsafe.
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..
Note 1: The initialization code now always consider 3 phases.
For 2-phase cases a trivial (0) state is returned.
Note 2: The initialization code does not compute a BlackoilStats,
but instead pass the initialization object with the initial state.
