One would think that such an assumption is safe in any case,
wouldn't one? But foen Eigen'S container this does not hold.
They do not provide STL compliant iterators, and access to them.
With this patch make the even stricter assumption that the containers
are random access and use operator[] instead of iterators.
As there are no functors for computing the minimum and maximum,
we convert the std::max and std::min function pointers to
functors (which is not really nice.) Previously we were somehow
tricked into using std::greater and std::less, which of course do
return true or false and not what we need. Additionally, do more
excessive testing with different ranges.
We need to compute quite a few global reductions in the
Newton method of opm-autodiff. This commit adds the functionality
to compute several reductions combined using only one global
communication. Compiles and test succeeds with one or more process.
With this commit the WellsManager will check the status of completions
before adding them to the internal struct wells
datastructure. Completions can be in the four states:
OPEN, SHUT, AUTO, POPN
Completions with state == SHUT will be ignored, wheras the wellsmanager
will throw if the states AUTO or POPN are encountered. The WELOPEN
keyword can also have the value 'STOP'; for completions that is
translated to 'SHUT' by Schedule object.
Rename the the meaning for shut as whats used in Eclipse.
STOP: Well stopped off above the formation. I.e. allow for flow in the
well.
SHUT: Well completely isolated from the formation. The well is removed
from the well list.
The old test was simply wrong: it computed the M-distance and compared
to the grid radius, which becomes dependent on the scaling of the
metric M. The corrected test in isClose() depends on the anisotropy
ratio of M and the grid radius.
Note that this patch does not introduce any real temperature
dependence but only changes the APIs for the viscosity and for the
density related methods. Note that I also don't like the fact that
this requires so many changes to so many files, but with the current
design of the property classes I cannot see a way to avoid this...
There were to identical if statements and the second one was followed
by an else branch. While in this case (if statement just throws) it is not
a bug, this commit cleans up one of the if statements.
gcc warned about the following
/home/mblatt/src/dune/opm/opm-core/opm/core/wells/WellsManager.cpp: In function ‘std::array<long unsigned int, 3ul> WellsManagerDetail::directionIndices(Opm::CompletionDirection::DirectionEnum)’:
/home/mblatt/src/dune/opm/opm-core/opm/core/wells/WellsManager.cpp:191: warning: control reaches end of non-void function
To calm it I introduced a throw clause after the switch statements. Thus adding a new
enum value will raise a warning on smart compilers, hopefully.
Shut wells are not added to the well list and the well index should
therefore not be increased when well control is set. This is similar to
whats is done for shut wells in createWellsFromSpecs.
Shut wells are not added to the well list and thus not considered in the
simulator.
The shut well test in test_wellsmanager is modified to assert this
behaviour.
BUG: This change provokes an assert in the EclipeWriter as number of
wells in wellstate is different from number of wells in the schedule.
The error checking macro makes it harder to read and harder to write, so
instead we now only check for functions that can contain errors. Bounds and
range checks are handled by PETSc and not OPM.
The previous implementation set plenty of values in the initialization list and
immediately overwrote these values with values looked up from the param group.
This patch makes it look up the parameteres from the param group argument,
making the constructor simpler.
Petsc only supports initialisation through the ParameterGroup constructor.
Calling the default, non-arg constructor is a static error, and not
implementing it makes using it break compiles.
call_petsc.c was really a thin C wrapper around the call to petsc itself and
turns out was mostly unnecessary C++ emulation. This removes the file entirely
and ports its functionality into LinearSolverPetsc.cpp.
All features from the file should now be more readable as well as properly
utilising modern C++ features.
The patch uses the CHKERRXX macro from petsc to handle errors reported by
petsc, and currently does not handle this and give the control back to OPM's
error/throw system.
Commit 96cf137 introduced support for Peaceman index calculation
that honoured general completion directions (X,Y,Z). This was
accomplished through a permutation index that reordered the
permeability and geometric extent components according to a local
coordinate system along the completion.
In a complete breakdown of logic, however, the d-component extent
vector was indexed as though it were a d-by-d matrix. This commit
restores sanity to the processing.
Pointy hat: @bska.
This commit extends the feature set of the WellsManager to support
horizontal ("X" and "Y") completions and include the net-to-gross
ratio in the Peaceman index ("Completion Transmissibility Factor,
CTF") of a well completion. The NTG factor is included if present
in the input deck represented by the "eclipseState".
There are two separate, though related, parts to this commit. The
first part splits the calculation of Peaceman's "effective radius"
out to a separate utility function, effectiveRadius(), and
generalises WellsManagerDetail::computeWellIndex() to account for
arbitrary directions and NTG factors. The second part uses
GridPropertyAccess::Compressed<> to extract the NTG vector from the
input if present while providing a fall-back value of 1.0 if no such
vector is available.
Note: We may wish to make the extraction policy configurable at some
point in the future.
This commit tightens the function header of method
WellsManager::createWellsFromSpecs()
to accept a reference-to-const 'cartesian_to_compressed' map. It
used to be a complete, copy-constructed object, so this is a slight
performance enhancement as we no longer need to copy a (somewhat)
large object on every call to the method.
This commit generalises the implementation of utility function
'getCubeDim' to support arbitrary number of space dimensions. In
actual practice there's no change in features as we only really use
a compile-time constant (= 3) to specify the number of space
dimensions.
This is a demonstration of using the
GridPropertyAccess::Compressed<>
class template. We save (some) memory by not creating the zero
fall-back vector in assignPermeability(), preferring instead to use
the fall-back/default mechanism of ArrayPolicy::ExtractFromDeck<>.
While here, adjust vector<PermComponent>::reserve() capacity to
reflect actual requirements.
Clients expect column-major (Fortran) ordering of the contiguous
"permeability_" array so that's what we create despite "tensor"
being row-major.
Suggested by: [at] atgeirr
This commit switches the assignment
diagonal = max(diagonal, minval)
to using a reference in the "diagonal" expression. This guarantees
that the indexing is done once which eases maintainability. While
here, replace the hard-coded dimension stride ('3') with the current
run-time dimension. This is mostly for symmetry because the overall
code is only really supported in three space dimension.
