Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct > Class Template Reference Solve mixed formulation of incompressible flow modelled by Darcy's law. More...
Inheritance diagram for Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >:
Detailed Descriptiontemplate<class GridInterface, class RockInterface, class BCInterface, template< class GridIF, class RockIF > class InnerProduct> class Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct > Solve mixed formulation of incompressible flow modelled by Darcy's law.
@f] The solver is based on a hybrid discretization scheme which yields a system of linear equations of the form
=
@f] where represents the interface fluxes for each interface for each cell, are the cell pressures and are the interface pressures. Through a Schur complement analysis, the above system of linear equations is reduced to an equivalent system of the form
=
@f] where , , and . Similarly, and . The system is the system of linear equations which is actually solved using separte linear system solver software. Then, a back substitution process yields the cell pressures and interface fluxes by solving the simpler systems
@f] Specifically, the matrix is diagonal (a single scalar per grid cell) and the matrix is available as a bi-product of the Schur reduction process. Finally, in the case of mimetic discretizations using the Definition: MimeticIPEvaluator.hpp:86 class, the matrix is directly available through an explicit formula. The matrix is a product of two parts–one which depends only on the grid (i.e., the topology and geomtry) and the geological properties (i.e., the permeability field) and one part which depends only on the temporally varying fluid data (i.e., viscosities and saturation dependent relative permeabilities). Furthermore, the matrices and depend only on the grid topolgy. Consequently, the cost of assembling the system may be reduced, at least for simulations involving multiple pressure solves, by performing all of the static (i.e., the parts dependent only on the grid and geological properties) assembly once, at system initalization. Then the system assembly process consists of calculating the saturation dependent contributions and adding these into the system of linear equations. The code is structured in a manner similar to traditional FEM software implementations. In particular, we assemble the coefficient matrix and system right hand side on a cell-by-cell basis. This yields a number of important simplifications. In particular, the matrix reduces to the identity on a single cell. Its effects are produced only through a local-to-global map of degrees of freedom. Similarly, on a single grid cell, the matrix with the number of elements equal to the number of interfaces (i.e., neighbours) of the cell. Finally, the matrix is computed as
where denotes the static part of and denotes the total fluid mobility in the grid cell. For ease of implementation of the back substitution process, we compute and store the values of , and during each system assembly process. A final quirk of the implementation is that we always solve for every interface pressure, even if a given pressure value is known through, e.g., a prescribed pressure boundary condition. This feature enables changing the type and value of a set of boundary conditions between pressure solves without having to reconstruct the sparsity structure of the coefficient matrix –at least while no connections are introduced or removed. Periodic boundary condtions introduce new connections (i.e., new non-zero coefficient matrix entries) so in order to gain maximum efficiency, you should initialize the flow solver system only after you know the existence of all periodic boundary conditions which will be employed in a given simulation. The use of non-periodic boundary conditions after periodic connections have been introduced is fully supported. This mode introduces a performance caveat. Specifically, a few entries which would otherwise not have been entered into the matrix due to being automatically zero will become explicit zeros instead. Consequently, each iteration of an iterative solver for the system becomes slightly more expensive as explicit zero-multiplications occur. Moreover, introducing explicit non-zero representation of matrix entries which are always zero increases the demand for memory resources. The flow solver is initialized in a three-step process. The first step, represented by method clear()
void clear() Clear all topologic, geometric and rock-dependent information currently held in internal data structu... Definition: IncompFlowSolverHybrid.hpp:498 , releases any previously held data in the internal data structures and prepares the solver system for defining a new problem. The second step, represented by the void initSystemStructure(const GridInterface &g, const BCInterface &bc) Compute structure of coefficient matrix in final system of linear equations for this flow problem.... Definition: IncompFlowSolverHybrid.hpp:534 enumerates the primary degrees of freedom (i.e., the interface pressure values) and determines, and allocates, the coefficient matrix non-zero structure. The third and final step, represented by method void computeInnerProducts(const RockInterface &r, const Point &grav) Compute static (i.e., independent of saturation) parts of the spatially varying inner products for e... Definition: IncompFlowSolverHybrid.hpp:565 , computes the static (i.e., geology and geomtry-dependent) inner product matrices . Method is offered separately in order to support solve several different property models on the same underlying geometry (grid). Finally, method init()
void init(const GridInterface &g, const RockInterface &r, const Point &grav, const BCInterface &bc) All-in-one initialization routine. Enumerates all grid connections, allocates sufficient space,... Definition: IncompFlowSolverHybrid.hpp:477 is a convenience method which calls the other initialization methods in sequence. Following solver intialization, a sequence of flow problems differing only by boundary condition type/value and/or differing fluid saturation values may be resolved by separate calls to the solve()
void solve(const FluidInterface &r, const std::vector< double > &sat, const BCInterface &bc, const std::vector< double > &src, double residual_tolerance=1e-8, int linsolver_verbosity=1, int linsolver_type=1, bool same_matrix=false, int linsolver_maxit=0, double prolongate_factor=1.6, int smooth_steps=1) Construct and solve system of linear equations for the pressure values on each interface/contact betw... Definition: IncompFlowSolverHybrid.hpp:658 method. At any time following a call to solve()
may the solution, represented by the type const FlowSolution & SolutionType Type representing the solution to the problem defined by the parameters to. Definition: IncompFlowSolverHybrid.hpp:818 , to the most recently resolved flow problem be retrieved through the SolutionType getSolution() Recover the solution to the problem defined by the parameters to method. Definition: IncompFlowSolverHybrid.hpp:828 method. We note that is always a reference-to-const.
Member Typedef Documentation◆ SolutionType
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
Type representing the solution to the problem defined by the parameters to. solve()
. Always a reference-to-const. The exposes methods pressure(c)
and outflux(f)
from which the cell pressure in cell *c
and outward-pointing flux across interface *f
may be recovered. Member Function Documentation◆ clear()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
Clear all topologic, geometric and rock-dependent information currently held in internal data structures. Release all memory resources in preparation of constructing a solver for a new problem. Method. clear()
must be called prior to any other method of the class. Referenced by Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::init(). ◆ computeInnerProducts()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
template<class Point >
Compute static (i.e., independent of saturation) parts of the spatially varying inner products for each grid cell. This is often a fairly expensive process, so in order to increase the speed of the system assembly we do not wish to perform this computation for each time step unless we have to. Moreover, if the permeability field changes but the grid connections remain static, we do not have to build a new matrix structure but need only compute new values for these static inner products.
Referenced by Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::init(). ◆ getSolution()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
◆ init()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
template<class Point >
All-in-one initialization routine. Enumerates all grid connections, allocates sufficient space, defines the structure of the global system of linear equations for the contact pressures, and computes the permeability dependent inner products for all of the grid's cells.
References Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::clear(), Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::computeInnerProducts(), and Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::initSystemStructure(). ◆ initSystemStructure()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
Compute structure of coefficient matrix in final system of linear equations for this flow problem. Allocates all storage needed by the flow solver itself.
Referenced by Opm::IncompFlowSolverHybrid< GridInterface, RockInterface, BCInterface, InnerProduct >::init(). ◆ postProcessFluxes()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
Postprocess the solution fluxes. This method modifies the solution object so that out-fluxes of twin faces (that is, the two faces on a cell-cell intersection) will be made antisymmetric.
◆ printStats()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
template<typename charT , class traits >
Print statistics about the connections in the current model. This is mostly for debugging purposes and should only rarely be used in client code.
◆ printSystem()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
Output current system of linear equations to permanent storage in files. One file for the coefficient matrix and one file for the right hand side. This is mostly useful whilst debugging the solver and should rarely be used from client code. The system is stored in a format which is suitable for importing into MATLAB or MATLAB-compatible software. In particular, using the MATLAB LOAD
and SPCONVERT
functions makes it easy to reconstruct the system of linear equations from within MATLAB.
◆ solve()
template<class GridInterface , class RockInterface , class BCInterface , template< class GridIF, class RockIF > class InnerProduct>
template<class FluidInterface >
Construct and solve system of linear equations for the pressure values on each interface/contact between neighbouring grid cells. Recover cell pressure and interface fluxes. Following a call to. method.
Specifically, the bc.flowCond(bid)
method is expected to yield a valid A class for representing a flow boundary condition. Definition: BoundaryConditions.hpp:122 object for which the methods pressure()
, pressureDifference()
, and outflux()
yield valid responses depending on the type of the object.
The documentation for this class was generated from the following file: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||