This needs to be done if a equilibration region transition is
mentioned by the THPRES keyword, but no value is given for this record
in the third item. (it seems that this is used quite frequently.)
Also, the approach taken by this patch also does not collide with the
restart machinery as far as I can see. This is because the initial
condition is applied by the simulator before the state at the restart
time is loaded. (I interpreted the code that way, but I could be
wrong, could anyone verify this?)
since it is pretty elaborate to calculate initial condition, this
patch is pretty messy. I also do not know if Eclipse does include
capillary pressure in this calculation or not (this patch does). Huge
kudos go to [at]totto82 for reviewing, testing and debugging this.
This should prevent misunderstandings about what the
well_index_on_proc is. It is not the well_index according to
the eclipse state (on open wells count) but the index of the
wells that are stored on this process' domain.
In the parallel run there are cases where wells perforate cells
that are neighbors of overlap/halo cells. On other process only
parts of the well are seen as perforations. These wells should be
ignored there. While the well was indeed ignored, the perforations
found where mistakenly added to the well found due not clearing the
wellperf_data[well_index]. This commit now does this clearing and
results in the right handling of wells for e.g. SPE9.
This is needed in parallel runs where the rock properties will not
be read from the deck but be communicated from a master process. Nevertheless
we need to be able to initialize the data structures with the correct
container size. In addition we need to be able to change the container values
from opm-autodiff's BlackoilPropsDataHandle.
This PR adds allow_cf to the wells structure that determine whether
crossflow is allowed or not. An extra argument is added to addWell(..)
to specify the allow_cf flag.
While hopefully not a bug it raises an exception with gcc's
libc debugging mode. Therefore we resort to using C++11's
std::vector::data instead.
The exception was rosen when running SPE9 in parallel.
This commit introduces a new public method, activeRegions(), that
retrieves those region IDs that contain at least one active cell.
We furthermore extend the cells() method to support lookup of
arbitrary region IDs. Non-active region IDs produce empty cell
ranges.
Intended use case is
for (const auto& reg : rmap.activeRegions()) {
const auto& c = rmap.cells(reg);
// use c
}
calculations
The dz calculated in WellDetails::getCubeDim is not correct in cases
where the face centroid of the horizontal faces is located above or
below the face centroid or the vertical faces. The cell thickness in
EclipseGrid, calculated using the Z-coordinates, is therefore used
instead.
Unused methods and arguments have been removed,
and we avoid including the EclMaterialLawManager
in the header. Clients IncompPropertiesFromDeck
and BlackoilPropertiesFromDeck have been updated.
If on one process a well completion is next to border then
it might also be stored in the neighbor process. Still not
all the completions of the well are known to the neighbor.
This breaks the previous assumption that for each well all
completions must belong to the partition of the process.
Therefore with this commit we allow wells that only have a
part of their completions assigned to the partition of the process.
This wells are deactivated under the assumption that they must
exist completely on another process due to the partitioning.
Previously well with just some shut completions errorneously triggered an
exception in parallel runs. This is fixed with this commit.
Due to the logic shut completions will always be marked as existing
on a process. (Initially all completions are marked as found. For
each open completion we check whether the cartesian index belongs to
the local grid. If that is not the case we mark it as not found).
Therefore we now check whether the found number of completions
is either the number of shut completions or the number of all completions.
In the former case the well is not stored on this process, and in the latter
case it is. In other cases we throw an exception.
gcc-4.7.2 (Debian 4.7.2-5) complained about:
"‘for’ loop initial declarations are only allowed in C99 mode
note: use option -std=c99 or -std=gnu99 to compile your code"
when seeing a loop like
for(int i=0; i<end; ++i)
This is fixed by moving the declaration before the for loop with
this commit. Altenatively, we could use the above option.
this makes it possible to switch to different saturation functions
again. So far the only supported function besides the default one is
the one which implements the "Stone 2" model.
this means the following changes:
- the "SatFuncGwseg" class is converted
- for now, Gwseg is the only saturation function supported by
SaturationPropsFromDeck. (will be changed in later commits.)
- the funcForCell() method of SaturationPropsFromDeck is removed as it
just occludes things
in any reasonable simulator which reads an ECL deck the deck is going
to decide which saturation function is to be used and not the outside
code. also, the table this which function will be using is not really the
calling code's business. (for any reasonable deck it is always going to
be a non-uniform table so it makes a lot of sense to avoid unnecessary
complexity IMO.)
this patch temporarily removes the ability to use anything except the
ECL default saturation function ("Gwseg"). this ability will be
restored later in this patch series.
namely BlackoilStateToFluidState which takes a BlackoilState object
and exposes it as a opm-material like fluid state object. Similar for
ExplicitArraysFluidState, which takes raw arrays.
since fluid states are a local API, the index of the cell to be used
for these two classes must be set externally. The advantage of this
concept is that it is possible to make "saturation functions" which
not only depend on saturations but also on arbitrary other quanties
(like temperature or phase composition) without having to change the
API of the "saturation" functions.
Bård spotet a bug after PR #805 was merged. Indead returning
-numeric_limits<type>::min() does not make sense for integral
values. This commit resorts to returning numeric_limits<type>::min().
Kudos to Bård for his attention.
This behaviour does not work for computing a global inner product.
Therfore this commit introduces a new function to the functor that
returns an appropriate initial value.
Previously we hardcoded float. Now we use the result_type of
the binary_function without any qualifiers. With any cv or reference
qualifiers std::numeric_limits uses a default implementation which
produces nonesense (e.g. numeric_limits<const int>::max() returns 0).
Previously, we used the setStatus method to set wells that do not
exist on the local grid to SHUT. Or at least this is what I thought
that ```well.setStatus(timestep, SHUT)```. Unfortunately, my
assumption was wrong. This was revealed while testing a parallel run
with SPE9 that threw an expeption about "Elements must be added in
weakly increasing order" in Opm::DynamicState::add(int, T). Seems like
the method name is a bit misleading.
As it turns out the WellManager has its own complete list of active
wells (shut wells are simply left out). Therefore we can use this
behaviour to our advantage: With this commit we not only exclude shut
wells from the list, but also the ones that do not exist on the local
grid. We even get rid of an ugly const_cast.
Currently, I have running a parallel SPE9 test that has not yet
aborted.
In this case the parallel index set might represent N entries (this might be the number of
cells of grid). Nevertheless, there several (n) equations/unknowns attached to each index.
In this case we construct a larger index set representing N*n unknows, where each unknown
is attached to an index.
This change only affects parallel runs.
In a parallel run each process only knows a part of the grid. Nevertheless
it does hold the complete well information. To resolve this the WellsManager
must be able to handle this case.
With this commit its constructor gets a flag indicating whether this is
a parallel run. If it is, then it does not throw if a well has cells that
are not present on the local part of the grid. Nevertheless it will check
that either all or none of the cells of a well are stored in the local part
of the grid.
Wells with no perforated cells on the local will still be present but set to SHUT.
This commit adds a verbose flag to the constructor of
SimulatorReport to allow for deactivating any
output to std:cout. This is handy for parallel runs where we only
want to print statistics on one process.
It does not make sense to report transport and pressure separately
for fully implicit solvers. It still makes sense to separate solver
from init and output though.
This commit updates the source code comment about using operator[] to
initialize the unordered map. Thanks to Bard's persistence we found
out that the cause is not the construction of the key value of type
std::string from const char* but the mapped type being a (mutable)
char* (due to C?).
This completes the PR #784.
g++-4.4 has problems converting const char* to char*
which it thinks is needed for constructing std::string.
Using operator[] circumvents this problem.
The compiler error fixed here was:
/usr/include/c++/4.4/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair(std::pair<_U1, _U2>&&) [with _U1 = const char*, _U2 = const char*, _T1 = const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, _T2 = char*]’:
/home/mblatt/src/dune/opm/opm-core/opm/core/linalg/LinearSolverPetsc.cpp:40: instantiated from here
/usr/include/c++/4.4/bits/stl_pair.h:107: error: invalid conversion from ‘const char*’ to ‘char*’
make[2]: *** [CMakeFiles/opmcore.dir/opm/core/linalg/LinearSolverPetsc.cpp.o] Fehler 1
Currently the keyword EQUIL is not supported by the fully
implicit blackoil simulator when using CpGrid. This
commit is a first step towards this as it makes the
implementation of initStateEquil generic.
Well, you never know. There are containers that use a signed integer
for storing its size. This results in a warning about comparing signed with
unsigned integers. This commit prevents this by explicitly casting the size
to std::size_t.
Due to the size of the overlap layer and the discretization scheme
the rhs might not contain correct values for overlap cells. This
commit makes sure they are correct by an additional communication step.
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.
