The region multipliers are no longer added to the cartesian logical
MULT[XYZ] structure. Instead a new method
getRegionMultiplier(globalIndex1, globalIndex2,FaceDir) is added that
return the multiplier between globalIndex1 cell and globalIndex2 cell.
The face direction is added to support directional dependent MULTREGT
input. This implementation of MULTREGT also supports restricting the
multipliers to only apply for NNC or NONNNC.
this is just the result of
```
find -iname "*.[ch]pp" | xargs sed -i "s/ *$//"
find opm/parser/share/keywords -type f | xargs sed -i "s/ *$//"
```
so if it causes conflicts with other patches, the others should get
priority. The rationale behind this patch is that some people tell
their editor to remove white space which leads to larger than
necessary patches...
This commit contains quite large changes to the EclipseGrid. The main
functional change is that the access to the ecl_grid_type pointer is
protected. In addition there are 'white space' changes due to methods
moving around and some methods have been marked static.
In many cases the only required information in an EclipseGrid instance
is the cartesian dimensions. To facilitate simpler testing - and not
have to create a full dummy grid the dimensions have been internalized
as a separate nx,ny,nz triplet. With this commit it is possible to
instantiate a grid with only dimensions, and no underlying ecl_grid_type
pointer.
seems like some compilers don't overwrite an inline method of a
template class with its specialization. A compiler warning would have
been nice to have in this case, though...
this fixes a really ugly and hard to find bug if EclipseState was
instanced multiple times: The EclipseState object passed to some of
these structures was destroyed, but the arrays stayed even if the next
EclipseState object was at a different location and also could use a
completely different grid...
this seems to be a compiler bug, but it could be something
else. Anyway, using multiple functions for the tests instead of nested
scopes is probably not the worst idea anyway...
For the petrophysical properties PERM? and PORO only the top layer must
be specified, cells further down can be copied from the layer
above. This functionality is implemented with a GridProperty
postprocessor.
The class MULTREGTSCanner internalizes the content of one or several
MULTREGT keywords and can then scan through GridProperty region objects
to find region interfaces as specified in the MULTREGT keyword.
this makes it possible to define more complicated initializers for
grid properties. (needed for example for keywords like ISGU.) This
patch does not introduce them yet, but only adds the necessary
infrastructure.
notes:
- to get around cyclic definitions in template classes, the
EclipseState is changed to a (defaulted) template parameter which
causes the compiler to only look up the class definition at
instantiation time.
- using std::shared_ptr in the property initializers would lead to
cyclic references which would cause memory leaks. To avoid that,
plain old references where used in most places. I think this is
okay as the GridProperty objects should be considered internal to
EclipseState and thus the EclipseState object should live at least
as long as GridProperty objects...
e.g. Eclipse specifies that for PERMX only the topmost layer needs to
be specified, i.e. the following is valid on a 3x3x3 grid
```
PERMX
9*10 /
```
the previous behaviour was to throw.
also, mark if data items have been defaulted, i.e., the item of
```
PERMX
* /
```
will now return true for 'defaultApplied()'.
