Commit afde0b02 authored by Bernd Flemisch's avatar Bernd Flemisch
Browse files

incorporated forgotten changes

git-svn-id: svn://svn.iws.uni-stuttgart.de/DUMUX/dumux/releases/2.0.1@5328 2fb0f335-1f38-0410-981e-8018bf24f1b0
parents e12e130a 8f4a7717
......@@ -184,7 +184,7 @@ add_subdirectory("tutorial")
# set up CTest
ENABLE_TESTING()
INCLUDE(CTest)
ADD_TEST(test_1p test/boxmodels/1p/test_1p test/boxmodels/1p/grids/test_1p_3d.dgf 1 1)
ADD_TEST(test_1p test/boxmodels/1p/test_1p test/boxmodels/1p/grids/test_1p_2d.dgf 1 1)
add_test(test_1p2c test/boxmodels/1p2c/test_1p2c test/boxmodels/1p2c/grids/test_1p2c.dgf 1 1)
add_test(test_2p test/boxmodels/2p/test_2p 1 1)
add_test(test_2pni test/boxmodels/2pni/test_2pni test/boxmodels/2pni/grids/test_2pni.dgf 1 1)
......@@ -194,7 +194,11 @@ add_test(test_richards test/boxmodels/richards/test_richards test/boxmodels/rich
add_test(test_propertysystem test/common/propertysystem/test_propertysystem)
add_test(test_spline test/common/spline/test_spline)
add_test(test_diffusion test/decoupled/1p/test_diffusion 1)
add_test(test_decoupled2p test/decoupled/2p/test_decoupled2p 1)
add_test(test_dec1p test/decoupled/1p/test_dec1p 3)
add_test(test_transport test/decoupled/2p/test_transport test/decoupled/2p/grids/test_transport.dgf 1)
add_test(test_impes test/decoupled/2p/test_impes 1)
add_test(test_dec2p2c test/decoupled/2p2c/test_dec2p2c)
add_test(test_multiphysics2p2c test/decoupled/2p2c/test_multiphysics2p2c)
add_test(tutorial_coupled tutorial/tutorial_coupled 1 1)
add_test(tutorial_decoupled tutorial/tutorial_decoupled 1)
......@@ -17,36 +17,37 @@ Getting started
In order to compile DuMuX, you first have to download and extract the
following DUNE modules into your source directory:
- DUNE-common from [1]
- DUNE-grid from [1]
- DUNE-istl from [1]
- DUNE-localfuctions from [1]
- DUNE-pdelab from [3]
- dune-common from [1]
- dune-grid from [1]
- dune-istl from [1]
- dune-localfuctions from [1]
- dune-pdelab from [2]
Since many simulators of DuMuX use the UG grid manager, it is recommended
to install it first [4].
Use the 2.0 release of the DUNE core modules and the 2.0 snapshot of
dune-pdelab.
Next, you need to decide whether you want to compile in debug or in
optimized mode and adapt the option file for the DUNE build system to
the path where you installed UG. The files are located in
$DUMUX_ROOT/optim.opts and $DUMUX_ROOT/debug.opts
respectively. ($DUMUX_ROOT is the directory where the unpacked files
of the DuMuX distribution are located.) Next, compile everything using
optimized mode. Example files are located in $DUMUX_ROOT/optim.opts
and $DUMUX_ROOT/debug.opts respectively. ($DUMUX_ROOT is the
directory where the unpacked files of the DuMuX distribution are
located.)
Next, compile everything with
./dune-common/bin/dunecontrol --opts=$(DUMUX_ROOT)/optim.opts --module=dumux all
Finally, install DUNE and DuMuX headers to your system using
Finally, install DUNE and DuMuX headers to your system by
./dune-common/bin/dunecontrol --module=dumux make install
A more comprehensive introduction to the DUNE build system can be
found in [2].
found in [3].
Links
-----
0. http://www.dune-project.org/doc/installation-notes.html
1. http://www.dune-project.org/download.html
2. http://www.dune-project.org/doc/buildsystem/buildsystem.pdf
3. http://www.dune-project.org/downloadext.html
4. http://www.dune-project.org/external_libraries/install_ug.html
2. http://www.dune-project.org/downloadext.html
3. http://www.dune-project.org/doc/buildsystem/buildsystem.pdf
Why CMake
=========
We use CMake 2.6 or higher as alternative to the build system provided
by DUNE. CMake is included in most GNU/Linux distributions or can be
downloaded at www.cmake.org. Using CMake has several advantages
compared to autotools:
You can use CMake 2.6 or higher as alternative to the build system
provided by DUNE. CMake is included in most GNU/Linux distributions
or can be downloaded at www.cmake.org. Using CMake has several
advantages compared to autotools:
- Out-of-tree builds are the default way to build software: The
directory where the source code resides won't get modified during
......@@ -74,3 +74,8 @@ cmake -DCMAKE_BUILD_TYPE=debug \
-DALUGrid_DIR=/usr/local/alugrid \
-DMETIS_DIR=/usr/local/metis \
path/to/DUMUX/source/directory
With gcc >= 4.5.0, compilation might fail due to an internal compiler
error. In this case, you might want to specify the compiler explicitly
by using the cmake options -DCMAKE_CXX_COMPILER and -DCMAKE_CC_COMPILER.
......@@ -3,7 +3,8 @@
# we need the module file to be able to build via dunecontrol
EXTRA_DIST = dune.module \
CMake/Modules/*.cmake CMakeLists.txt \
CONTRIBUTORS INSTALL.cmake LICENSE
CONTRIBUTORS INSTALL.cmake LICENSE \
debug.opts optim.opts
SUBDIRS = appl doc dumux m4 test tutorial
......
......@@ -2,6 +2,8 @@ check_PROGRAMS = lens_1p2c lens_2p
noinst_HEADERS = *.hh
EXTRA_DIST = interface1p2c.xml interface2p.xml
lens_1p2c_SOURCES = lens_1p2c.cc
lens_2p_SOURCES = lens_2p.cc
......
\chapter{Getting started}
First, we describe the steps which are necessary for the installation of \Dumux. Then a quick start guide for the first \Dumux experience is provided. We conclude this chapter with a copy of the \Dune coding guidelines.
First, we describe the prerequisites and the steps which are necessary for the installation of \Dumux. Then a quick start guide for the first \Dumux experience is provided. We conclude this chapter with a copy of the \Dune coding guidelines.
\input{install}
\input{quickstart-guide}
......
......@@ -2,8 +2,8 @@
\label{guidelines}
This section quotes the DUNE coding guidelines found at \cite{DUNE-HP}.
These guidelines also should be followed by every \Dumux developer and user.
"In order to keep the code maintainable we have decided upon a set of coding rules.
These guidelines also should be followed by every \Dumux developer and user. \\
``In order to keep the code maintainable we have decided upon a set of coding rules.
Some of them may seem like splitting hairs to you, but they do make it much easier
for everybody to work on code that hasn't been written by oneself.
......@@ -34,5 +34,5 @@ of documentation is documented, and it is easier to get rid of it systematically
The use of exceptions for error handling is encouraged. Until further notice, all exceptions thrown are DuneEx.
\item Debugging Code:
Global debugging code is switched off by setting the symbol NDEBUG. In particular, all asserts are
automatically removed. Use those asserts freely!
automatically removed. Use those asserts freely!''
\end{itemize}
This diff is collapsed.
\section{Setup of a New Folder}
In this section setting up a new folder is described. In fact it is very easy to create a new folder, but getting \Dumux to know the new folder takes some steps which will be explained in mroe detail below:
In this section setting up a new folder is described. In fact it is very easy to create a new folder, but getting \Dumux to know the new folder takes some steps which will be explained in more detail below:
\begin{itemize}
\item create new folder with content
\item adapt \verb+Makefile.am+
\item insert new folder in \verb+Makefile.am+ of the directory above
\item adapt \verb+configure.ac+ in the \verb+$DUMUX_ROOT+ (the directory you checked out, probably dune-mux)
\item adapt \verb+configure.ac+ in the \verb+$DUMUX_ROOT+ (the directory you checked out, probably dumux)
\item newly compile \Dumux
\end{itemize}
\noindent In more detail:
\textbf{First} of all, the new folder including all relevant files needs to be created (see Section \ref{tutorial-coupled} and \ref{tutorial-decoupled} for desccription of a problem).
\textbf{First} of all, the new folder including all relevant files needs to be created (see Section \ref{tutorial-coupled} and \ref{tutorial-decoupled} for description of a problem).
\textbf{Second}, a new \verb+Makefile.am+ for the new Folder needs to be created. It is good practize to simply copy an existing file. For example the file \verb+$DUMUX_ROOT/test/2p/Makefile.am+ looks as follows:
\textbf{Second}, a new \verb+Makefile.am+ for the new Folder needs to be created. It is good practice to simply copy an existing file. For example the file \verb+$DUMUX_ROOT/test/2p/Makefile.am+ looks as follows:
\begin{verbatim}
bin_PROGRAMS = test_2p
......@@ -25,7 +25,7 @@ test_2p_LDADD = $(MPI_LDFLAGS)
include $(top_srcdir)/am/global-rules
\end{verbatim}
All occurences of \verb+test_2p+ need to be replaced by the name of the new project, e.g. \verb+New_Project+. At least if the name of the source file as well as the name of the new project are \verb+New_Project+.
All occurrences of \verb+test_2p+ need to be replaced by the name of the new project, e.g. \verb+New_Project+. At least if the name of the source file as well as the name of the new project are \verb+New_Project+.
\textbf{Third}: In the directory above your new Project there is also a \verb+Makefile.am+ . In this file the subdirectories are listed. As you introduced a new subdirectory, it needs to be included here. In this case the name of the new Folder is \verb+New_Project+ . Don't forget the trailing backslash.
......
......@@ -3,8 +3,8 @@
The previous chapter showed, how to install and compile \Dumux. This chapter shall give a very brief introduction, how to run a first test application and how to visualize the first output files. Only the rough steps will be described here. More detailed explanations can be found in the tutorials in the following chapter.
\begin{enumerate}
\item Go to the directory \texttt{/test}. There, various test application folders can be found. Let us consider as example \texttt{test{\_}2p}:
\item Enter the folder \texttt{2p}. If everyting was compiled correctly, there should be an executable \texttt{test{\_}2p}. Otherwise, type \texttt{make test{\_}2p} in order to compile the application. To run the simulation, type\\
\item Go to the directory \texttt{/test}. There, various test application folders can be found. Let us consider as example \texttt{boxmodels/test{\_}2p}:
\item Enter the folder \texttt{boxmodels/2p}. If everything was compiled correctly, there should be an executable \texttt{test{\_}2p}. Otherwise, type \texttt{make test{\_}2p} in order to compile the application. To run the simulation, type\\
\texttt{./test{\_}2p 1e4 1e2}\\
into the console. The parameters that are used here are the end time of the simulation and the initial timestep size. The parameters that are required when calling the application are specified in the application file (here: test{\_}2p.cc).
\item The simulation starts and produces some .vtu output files and also a .pvd file. The .pvd file can be used to examine time series and summarizes the .vtu-files. It is possible to stop a running application by pressing $<ctrl><c>$.
......
......@@ -275,41 +275,43 @@ The problem class always has at least five methods:
condition.
\end{itemize}
For the definition of the the boundary condition types and of the values of the Dirichlet boundaries,
two parameters are required:
\begin{description}
\item [values:] A vector which stores the result of the method. What
the values in this vector mean is depending on the method: For
\texttt{dirichlet()} it contains the actual values of the primary
variables, for \texttt{boundaryTypes()} it contains the boundary
condition type. It has as many entries as the model has primary variables / equations.
For the typical case where all equations have the same boundary
condition at a certain position, there are two methods that set the appropriate conditions
for all primary variables / equations: Either \texttt{setAllDirichlet()} or \texttt{setAllNeumann()}
\item [vertex:] The boundary condition and the Dirichlet values are specified at the vertex, which represents a
subcontrol volume. This avoids to specify two different boundary condition types at one subcontrol volume.
Be aware that the second parameter is a Dune grid entity with the codimension dim.
\end{description}
To ensure that no boundaries are undefined, a small safeguard value \texttt{eps\_}
is usually added when comparing spatial coordinates. The left boundary is
hence not assigned where the first coordinate is equal to zero, but where it is
smaller than a very small value \texttt{eps\_}.
Methods which make statements about boundary segments of the grid (i.e.
\texttt{boundaryTypes()}, \texttt{dirichlet()} and \texttt{neumann()}) get
six parameters. The first parameter differs if the type of the boundary condition
is defined \texttt{boundaryTypes()}:
\texttt{neumann()}) get six parameters:
\begin{description}
\item[BCtypes:] A container which stores the type of the boundary condition
for each equation. For the typical case where all equations have the same boundary
condition at a certain position, there are two methods that set the appropriate conditions
for all primary variables / equations: Either \texttt{setAllDirichlet()} or \texttt{setAllNeumann()}.
\item[values:] A vector \texttt{neumann()}, in which the mass fluxes per area unit
over the boundary segment are specified.
\item[element:] The element of the grid where the boundary segment
is located.
\item[fvElemGeometry:] The finite-volume geometry induced on the
finite element by the box scheme.
\item[isIt:] The \texttt{IntersectionIterator} of the boundary
segement as given by the grid
\item[isIt:] The \texttt{Intersection} of the boundary
segment as given by the grid.
\item[scvIdx:] The index of the sub-control volume in
\texttt{fvElementGeometry} adjacent to the boundary segment.
\item[boundaryFaceIdx:] The index of the boundary face in
\texttt{fvElementGeometry} which represents the boundary segment.
\end{description}
To ensure that no boundaries are undefined, a small safeguard value \texttt{eps\_}
is usually added when compariing spatial coordinates. The left boundary is
hence not assigned where the first coordinate is equal to zero, but where it is
smaller than a very small value \texttt{eps\_}.
After the type of the boundary condition is defined, their values have to be
assigned with the methods \texttt{dirichlet()} and \texttt{neumann()} which only differ
by the first function parameter:
\begin{description}
\item[values:] A vector which stores the result of the method. What
the values in this vector mean is dependent on the method: For
\texttt{dirichlet()} it contains the values of the primary
variables, for \texttt{neumann()} the mass fluxes per area unit
over the boundary segment.
\end{description}
Similarly, the \texttt{initial()} and \texttt{source()} methods
specify properties of sub-control volumes and thus only get
......@@ -321,7 +323,10 @@ methods. If the isothermal two-phase model is used, this includes
for example a \texttt{temperature()} method which returns the temperature in Kelvin
of the fluids and the rock matrix in the domain. This temperature is
then used by the model to calculate fluid properties which possibly
depend on it, e.g. density.
depend on it, e.g. density. The \texttt{bboxMax()} method that is used here, is a vector
that provides information about the spatial extends of the simulation domain. This method
and the respective \texttt{bboxMin()} method
can be found in the base class \texttt{Dumux::BoxProblem<TypeTag>}.
\subsection{Defining fluid properties}\label{tutorial-coupled:description-fluid-class}
......@@ -425,7 +430,7 @@ to make some small changes in the tutorial files.
\begin{enumerate}
\item \textbf{Run the Model} \\
To get an impression what the results should look like you can first run the original version of the coupled tutorial model by typing \texttt{./tutorial\_coupled 5e5 10}. The first number behind the simulation name defines the timespan of the simulation run in seconds, the second number defines the initial time step size. Note that the time step size is automatically optimized during the simulation. For the visualisation with paraview please refer to \ref{quick-start-guide}.\\
To get an impression what the results should look like you can first run the original version of the coupled tutorial model by typing \texttt{./tutorial\_coupled 5e5 10}. The first number behind the simulation name defines the timespan of the simulation run in seconds, the second number defines the initial time step size. Note that the time step size is automatically optimized during the simulation. For the visualization with paraview please refer to \ref{quick-start-guide}.\\
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\
Change the size of the model domain so that you get a rectangle with
......@@ -446,13 +451,13 @@ To get an impression what the results should look like you can first run the ori
Now you can change the fluids. Use DNAPL instead of Oil and Brine instead of Water. To do that you have to select different components via the property system in the problem file:
\begin{enumerate}
\item Brine: The class \texttt{Dumux::Brine} acts as a adapter to the fluid system that alters a pure water class by adding some salt. Hence, the class \texttt{Dumux::Brine} uses a pure water class, such as \texttt{Dumux::H2O}, as a second template argument after the data type \texttt{<Scalar>} as a template argument (be aware to use the complete water class with its own template parameter).
\item DNAPL: A standard set of chemical substances, such as Oil and Brinde, is already included (via a list of \texttt{\#include ..} commandos) and hence easy accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file as well as select the component via the property system.
\item DNAPL: A standard set of chemical substances, such as Oil and Brine, is already included (via a list of \texttt{\#include ..} commandos) and hence easy accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file as well as select the component via the property system.
\end{enumerate}
If you want to take a closer look how the fluid classes are defined and which substances are already available please browse through the files in the directory
\texttt{/dumux/material/components}.
\item \textbf{Use the \Dumux fluid system} \\
\Dumux usually organises fluid mixtures via a \texttt{fluidsystem}. In order to include a fluidsystem you first have to comment the lines \ref{tutorial-coupled:2p-system-start} to \ref{tutorial-coupled:2p-system-end} in the problem file. If you use eclipse, this can easily be done by pressing \textit{str + shift + 7} -- the same as to cancel the comment later on.\\
\Dumux usually organizes fluid mixtures via a \texttt{fluidsystem}. In order to include a fluidsystem you first have to comment the lines \ref{tutorial-coupled:2p-system-start} to \ref{tutorial-coupled:2p-system-end} in the problem file. If you use eclipse, this can easily be done by pressing \textit{str + shift + 7} -- the same as to cancel the comment later on.\\
Now include the file \texttt{fluidsystems/h2o\_n2\_system.hh} in the material folder, and set a property \texttt{FluidSystem} with the appropriate type, \texttt{Dumux::H2O\_N2\_System<TypeTag>}. However, the complicated fluidsystem uses tabularized fluid data, which need to be initialized in the constructor body of the current problem by adding \texttt{GET\_PROP\_TYPE(TypeTag, PTAG(FluidSystem))::init();}, hence using the initialization function of the applied fluidsystem. As water flow replacing a gas is much faster, test your simulation only until 2e3 seconds and start with a time step of 1 second.\\
Please reverse the changes of this example, as we still use bulk phases and hence do not need such an extensive fluid system.
......@@ -488,7 +493,7 @@ When does the front cross the material border? In paraview, the option \textit{V
\end{enumerate}
\subsubsection{Exercise 2}
For this exercise you should create a new proplem file analogous to
For this exercise you should create a new problem file analogous to
the file \texttt{tutorialproblem\_coupled.hh} (e.g. with the name
\texttt{ex2\_tutorialproblem\_coupled.hh} and new spatial parameters
just like \texttt{tutorialspatialparameters\_coupled.hh}. The new problem file needs to
......
......@@ -249,7 +249,7 @@ be included in the file \texttt{tutorial\_decoupled.cc}.
The new files should contain the definition of a new classes with
names that relate to the file name, such as \texttt{Ex2TutorialProblemDecoupled}.
Make sure that you also adjust the guardian
macros in lines \ref{tutorial-decoupled:guardian1} and \ref{tutorial-decoupled:guardian1}
macros in lines \ref{tutorial-decoupled:guardian1} and \ref{tutorial-decoupled:guardian2}
in the header files (e.g. change \\
\texttt{DUMUX\_TUTORIALPROBLEM\_DECOUPLED\_HH} to
\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_DECOUPLED\_HH}). Besides also adjusting the guardian macros,
......@@ -269,7 +269,7 @@ $x$-direction and $10$ cells in $y$-direction. The simulation time
should be set to $2e4 \text{s}$.
Now include your new problem file in the main file and replace the
\texttt{TutorialProblemCoupled} type tag by the one you've created and
\texttt{TutorialProblemDecoupled} type tag by the one you've created and
compile the program.
......
// $Id$
/*****************************************************************************
* Copyright (C) 2010 by Katherina Baber, Klaus Mosthaf *
* Copyright (C) 2008-2009 by Bernd Flemisch, Andreas Lauser *
* Institute of Hydraulic Engineering *
* University of Stuttgart, Germany *
* email: <givenname>.<name>@iws.uni-stuttgart.de *
* *
* This program is free software: you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation, either version 2 of the License, or *
* (at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with this program. If not, see <http://www.gnu.org/licenses/>. *
*****************************************************************************/
/*!
* \file
*
* \brief This file contains the data which is required to calculate
* all fluxes of the fluid phase over the boundary of a finite volume.
*
* This means pressure and temperature gradients, phase densities at
* the integration point of the boundary, etc.
*/
#ifndef DUMUX_2P2C_BOUNDARY_VARIABLES_HH
#define DUMUX_2P2C_BOUNDARY_VARIABLES_HH
#include <dumux/common/math.hh>
namespace Dumux
{
/*!
* \ingroup TwoPTwoCModel
* \brief This template class contains the data which is required to
* calculate the fluxes of the fluid phases over the boundary of a
* finite volume for the 2p2c model.
*
* This means pressure and velocity gradients, phase density and viscosity at
* the integration point of the boundary, etc.
*/
template <class TypeTag>
class TwoPTwoCBoundaryVariables
{
typedef typename GET_PROP_TYPE(TypeTag, PTAG(Scalar)) Scalar;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(GridView)) GridView;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(Problem)) Problem;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(VolumeVariables)) VolumeVariables;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(ElementVolumeVariables)) ElementVolumeVariables;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(TwoPTwoCIndices)) Indices;
enum {
dim = GridView::dimension,
};
typedef typename GridView::template Codim<0>::Entity Element;
typedef Dune::FieldVector<Scalar, dim> VelocityVector;
typedef Dune::FieldVector<Scalar, dim> ScalarGradient;
typedef Dune::FieldMatrix<Scalar, dim, dim> VectorGradient;
typedef typename GET_PROP_TYPE(TypeTag, PTAG(FVElementGeometry)) FVElementGeometry;
typedef typename FVElementGeometry::SubControlVolume SCV;
typedef typename FVElementGeometry::BoundaryFace BoundaryFace;
enum {
lPhaseIdx = Indices::lPhaseIdx,
gPhaseIdx = Indices::gPhaseIdx,
lCompIdx = Indices::lCompIdx,
gCompIdx = Indices::gCompIdx,
numPhases = GET_PROP_VALUE(TypeTag, PTAG(NumPhases))
};
public:
TwoPTwoCBoundaryVariables(const Problem &problem,
const Element &element,
const FVElementGeometry &elemGeom,
int boundaryFaceIdx,
const ElementVolumeVariables &elemDat,
int scvIdx)
: fvElemGeom_(elemGeom), scvIdx_(scvIdx)
{
boundaryFace_ = &fvElemGeom_.boundaryFace[boundaryFaceIdx];
for (int phaseIdx = 0; phaseIdx < numPhases; ++phaseIdx) {
densityAtIP_[phaseIdx] = Scalar(0);
pressureAtIP_[phaseIdx] = Scalar(0);
molarDensityAtIP_[phaseIdx] = Scalar(0);
potentialGrad_[phaseIdx] = Scalar(0);
concentrationGrad_[phaseIdx] = Scalar(0);
molarConcGrad_[phaseIdx] = Scalar(0);
}
calculateBoundaryValues_(problem, element, elemDat);
};
Scalar KmvpNormal(int phaseIdx) const
{ return KmvpNormal_[phaseIdx]; }
/*!
* \brief The binary diffusion coefficient for each fluid phase.
*/
Scalar porousDiffCoeff(int phaseIdx) const
{ return porousDiffCoeff_[phaseIdx]; };
/*!
* \brief Return density \f$\mathrm{[kg/m^3]}\f$ of a phase at the integration
* point.
*/
Scalar densityAtIP(int phaseIdx) const
{ return densityAtIP_[phaseIdx]; }
/*!
* \brief Return molar density \f$\mathrm{[mol/m^3]}\f$ of a phase at the integration
* point.
*/
Scalar molarDensityAtIP(int phaseIdx) const
{ return molarDensityAtIP_[phaseIdx]; }
/*!
* \brief The concentration gradient of a component in a phase.
*/
const ScalarGradient &concentrationGrad(int phaseIdx) const
{ return concentrationGrad_[phaseIdx]; };
/*!
* \brief The molar concentration gradient of a component in a phase.
*/
const ScalarGradient &molarConcGrad(int phaseIdx) const
{ return molarConcGrad_[phaseIdx]; };
const FVElementGeometry &fvElemGeom() const
{ return fvElemGeom_; }
const BoundaryFace& boundaryFace() const
{ return *boundaryFace_; }
protected:
void calculateBoundaryValues_(const Problem &problem,
const Element &element,
const ElementVolumeVariables &elemDat)
{
ScalarGradient tmp(0.0);
// calculate gradients and secondary variables at IPs of the boundary
for (int idx = 0;
idx < fvElemGeom_.numVertices;
idx++) // loop over adjacent vertices
{
// FE gradient at vertex idx
const ScalarGradient& feGrad = boundaryFace_->grad[idx];
// compute sum of pressure gradients for each phase
for (int phaseIdx = 0; phaseIdx < numPhases; phaseIdx++)
{
// the pressure gradient
tmp = feGrad;
tmp *= elemDat[idx].pressure(phaseIdx);
potentialGrad_[phaseIdx] += tmp;
}
// the concentration gradient of the non-wetting
// component in the wetting phase
tmp = feGrad;
tmp *= elemDat[idx].fluidState().massFrac(lPhaseIdx, gCompIdx);
concentrationGrad_[lPhaseIdx] += tmp;
tmp = feGrad;
tmp *= elemDat[idx].fluidState().moleFrac(lPhaseIdx, gCompIdx);
molarConcGrad_[lPhaseIdx] += tmp;
// the concentration gradient of the wetting component
// in the non-wetting phase
tmp = feGrad;
tmp *= elemDat[idx].fluidState().massFrac(gPhaseIdx, lCompIdx);
concentrationGrad_[gPhaseIdx] += tmp;
tmp = feGrad;
tmp *= elemDat[idx].fluidState().moleFrac(gPhaseIdx, lCompIdx);
molarConcGrad_[gPhaseIdx] += tmp;
for (int phaseIdx=0; phaseIdx < numPhases; phaseIdx++)
{
pressureAtIP_[phaseIdx] += elemDat[idx].pressure(phaseIdx)*boundaryFace_->shapeValue[idx];
densityAtIP_[phaseIdx] += elemDat[idx].density(phaseIdx)*boundaryFace_->shapeValue[idx];
molarDensityAtIP_[phaseIdx] += elemDat[idx].molarDensity(phaseIdx)*boundaryFace_->shapeValue[idx];
}
}
for (int phaseIdx=0; phaseIdx < numPhases; phaseIdx++)
{
tmp = problem.gravity();
tmp *= densityAtIP_[phaseIdx];
potentialGrad_[phaseIdx] -= tmp;
Scalar k = problem.spatialParameters().intrinsicPermeability(element, fvElemGeom_, scvIdx_);
VectorGradient K(0);
K[0][0] = K[1][1] = k;
ScalarGradient Kmvp;
K.mv(potentialGrad_[phaseIdx], Kmvp);
KmvpNormal_[phaseIdx] = - (Kmvp*boundaryFace_->normal);
const VolumeVariables &vertDat = elemDat[scvIdx_];
if (vertDat.saturation(phaseIdx) <= 0)
porousDiffCoeff_[phaseIdx] = 0.0;
else
{
Scalar tau = 1.0/(vertDat.porosity()*vertDat.porosity())*
pow(vertDat.porosity()*vertDat.saturation(phaseIdx), 7.0/3);
porousDiffCoeff_[phaseIdx] = vertDat.porosity()*vertDat.saturation(phaseIdx)*tau*vertDat.diffCoeff(phaseIdx);
}
}
}
const FVElementGeometry &fvElemGeom_;
const BoundaryFace *boundaryFace_;
// gradients
ScalarGradient potentialGrad_[numPhases];
ScalarGradient concentrationGrad_[numPhases];
ScalarGradient molarConcGrad_[numPhases];
// density of each face at the integration point
Scalar pressureAtIP_[numPhases];
Scalar densityAtIP_[numPhases];
Scalar molarDensityAtIP_[numPhases];
// intrinsic permeability times pressure potential gradient
// projected on the face normal
Scalar KmvpNormal_[numPhases];
// the diffusion coefficient for the porous medium
Scalar porousDiffCoeff_[numPhases];
int scvIdx_;
};
} // end namespace
#endif
......@@ -40,6 +40,7 @@
#include "2p2cfluidstate.hh"
#include "2p2cproperties.hh"
#include "2p2cnewtoncontroller.hh"
#include "2p2cboundaryvariables.hh"
namespace Dumux
{
......@@ -134,6 +135,9 @@ SET_TYPE_PROP(BoxTwoPTwoC, VolumeVariables, TwoPTwoCVolumeVariables<TypeTag>);
//! the FluxVariables property
SET_TYPE_PROP(BoxTwoPTwoC, FluxVariables, TwoPTwoCFluxVariables<TypeTag>);
//! the BoundaryVariables property
SET_TYPE_PROP(BoxTwoPTwoC, BoundaryVariables, TwoPTwoCBoundaryVariables<TypeTag>);
//! the upwind factor for the mobility.
SET_SCALAR_PROP(BoxTwoPTwoC, MobilityUpwindAlpha, 1.0);
......
......@@ -240,8 +240,8 @@ public:
};
if (enablePartialReassemble) {
if (gridView_().comm().size() > 1)
greenElems_ = gridView_().comm().sum(greenElems_);
if (gridView_().comm().size() > 1)
greenElems_ = gridView_().comm().sum(greenElems_);
reassembleTolerance_ = nextReassembleTolerance_;