diff --git a/.gitignore b/.gitignore index b1049dfc4ca62ffabc5183ee43adf683091b651c..2e5717d90b4e2e2ff3b4b116b15ebef5f8d25e93 100644 --- a/.gitignore +++ b/.gitignore @@ -8,6 +8,14 @@ *.parh *.tarh +# ignore matrix-market files +*.mtx + +error.txt +lint.txt + # ignore build directories build*/ -install*/ \ No newline at end of file +install*/ + +.vscode/ \ No newline at end of file diff --git a/CMakeLists.txt b/CMakeLists.txt index 7de534f765097fc7737a9b63b410f2eb95141495..610c5f74d05630677b3a6a3e703fdda26ca68cf0 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -1,8 +1,6 @@ cmake_minimum_required(VERSION 3.1) project(dune-amdis CXX) -#set(CXX_MAX_STANDARD 14 CACHE BOOL "" FORCE) - if(NOT (dune-common_DIR OR dune-common_ROOT OR "${CMAKE_PREFIX_PATH}" MATCHES ".*dune-common.*")) string(REPLACE ${CMAKE_PROJECT_NAME} dune-common dune-common_DIR diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 36842ca089f2173b3c98d450a43e61a51c5d4561..d609a51b97368d947fff92140a344275108ce657 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,23 +1,33 @@ # GIT Workflow -Follow the ideas of [a-successful-git-branching-model](http://nvie.com/posts/a-successful-git-branching-model), especially -- Create a new branch for all new features, following the naming convention `feature/XYZ` +Follow the ideas of [a-successful-git-branching-model](http://nvie.com/posts/a-successful-git-branching-model), +especially +- Create a new branch for all new features, following the naming convention + `feature/XYZ` - Merge features in the `develop` branch only - Correct Bugs in issue branches, following the naming convention `issue/XYZ` -- Merge issues in the `develop` branch, except when it is a hotfix, then merge to `master` and `develop` +- Merge issues in the `develop` branch, except when it is a hotfix, then merge + to `master` and `develop` - For all merges create a meaningful *Merge Request* in GitLab # Code Style-Guide -This style-guide is intended for developers writing code for AMDiS, is not complete and probably not applied to all parts of the AMDiS code. Feel free to edit existing source files in order to fulfill the styles. +This style-guide is intended for developers writing code for AMDiS, is not complete +and probably not applied to all parts of the AMDiS code. Feel free to edit existing +source files in order to fulfill the styles. -Parts of this convention are taken from well established style guides, like the *Google C++ Style Guide*. +Parts of this convention are taken from well established style guides, like the +*Google C++ Style Guide*. In general, the code should follow the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines). ## File naming conventions -Filenames should be mixed lower and upper case, starting with an uppercase letter. They should not include underscores or dashed. Use an uppercase letter to indicate a new subword. Sourcefiles should end in `.cpp` and header files should end in `.hpp`. In case you move the code of a template class to a separate file, included textually at the end of the corresponding header file, use the extensions `.inc.hpp`. +Filenames should be mixed lower and upper case, starting with an uppercase letter. +They should not include underscores or dashed. Use an uppercase letter to indicate +a new subword. Sourcefiles should end in `.cpp` and header files should end in `.hpp`. +In case you move the code of a template class to a separate file, included textually +at the end of the corresponding header file, use the extensions `.inc.hpp`. The name of a file should follow the name of the implemented class in this file. @@ -26,21 +36,26 @@ Examples of valid filenames: * `AdaptInstat.cpp` * `DOFVector.hpp` * `DOFVector.cpp` -* `DOFVector.inc.hpp` (the implementation of the methods of the template class `DOFVector<T>`) +* `DOFVector.inc.hpp` (the implementation of the methods of the template class + `DOFVector<T>`) -Do not use filenames that already exist in /usr/include or are stdandard C/C++ include files, such as `math.h` (remember that windows files-systems are case insensitive and thus, there is no difference between `math.h` and `Math.H`.) +Do not use filenames that already exist in /usr/include or are stdandard C/C++ include +files, such as `math.h` (remember that windows files-systems are case insensitive and +thus, there is no difference between `math.h` and `Math.H`.) ## Generale file structure -Every header file should start with a copyright notice and an include guard `#pragma once`, where the text of the copyright notice is given in the file `tools/license.templ.txt` and can automatically by added, using the script files in the `tools` directory: +Every header file should start with a copyright notice and an include guard `#pragma once`, +where the text of the copyright notice is given in the file `tools/license.templ.txt` +and can automatically by added, using the script files in the `tools` directory: ``` c++ -// Software License for dune-amdis +// Software License for AMDiS // // Copyright (c) 2015 Institute for Scientific Computing, Technische Universitaet Dresden // All rights reserved. // Authors: Simon Praetorius // -// This file is part of the dune-amdis Library +// This file is part of the AMDiS Library // see also the LICENSE file in the distribution. #pragma once @@ -50,14 +65,18 @@ After the include guard a list of include files can be added, see *Names and Ord ### Names and Order of Includes -All of a project's header files should be listed as descendants of the project's source directory. The includes should be grouped following the rules: -* [class header file] ... for source files that implement an interface specified in a header file +All of a project's header files should be listed as descendants of the project's +source directory. The includes should be grouped following the rules: +* [class header file] ... for source files that implement an interface specified + in a header file * C system files. * C++ system files. * Other external libraries' header files. * Your project's header files. -For better readability a comment above each group can be added. Within each section the includes should be ordered alphabetically. Project's header files should be surrounded by `"`, while external header files should be surrounded by `<...>`. +For better readability a comment above each group can be added. Within each section +the includes should be ordered alphabetically. Project's header files should be +surrounded by `"`, while external header files should be surrounded by `<...>`. For example, the includes in `io/VtkWriter.cpp` might look like this: @@ -86,7 +105,8 @@ For example, the includes in `io/VtkWriter.cpp` might look like this: ### Namespaces -All implementation should be put into the namespace `AMDiS`. When a namespace closes, a corresponding comment should be added to the closing brackets: +All implementation should be put into the namespace `AMDiS`. When a namespace closes, +a corresponding comment should be added to the closing brackets: ``` c++ namespace AMDiS @@ -95,7 +115,9 @@ namespace AMDiS } // end namespace AMDiS ``` -Implementation details are put into a subnamespace `Impl`. A few more subnamespaces of `AMDiS` are allowed, e.g., `Concepts`. If onw of these subnamespaces need another subsubnamespace for implementation details, it should be names `_Impl`. +Implementation details are put into a subnamespace `Impl`. A few more subnamespaces +of `AMDiS` are allowed, e.g., `Concepts`. If one of these subnamespaces need another +subsubnamespace for implementation details, it should be named `Impl_`. ## Line length @@ -112,4 +134,5 @@ Use two spaces instead of tabs! ## Documentation -Use Doxygen-Style comments for the documentation of functions and classes, except when the function name already indicates its meaning completely. +Use Doxygen-Style comments for the documentation of functions and classes, except +when the function name already indicates its meaning completely. diff --git a/README.md b/README.md index 6b053c6545ef299987a263982e8dcb94fe75d955..14b81d8171f7427e899cc54e2d853a64c472bed1 100644 --- a/README.md +++ b/README.md @@ -1,30 +1,45 @@ -Preparing the Sources -========================= - -The project *dune-amdis* requires a modern compiler supporting c++14 standard -and an up-to-date cmake >= 3.1 installed on the system. +AMDiS +===== +The *Adaptive Multi-Dimensional Simulation Toolbox* (AMDiS) is implemented as a +discretization module on top of the Dune framework. + +Installation +============ +We provide a *cmake*-based configuration and use the `dunecontrol` build system. +Simply run -Installation using dune-docker ------------------------------- +``` +dunecontrol --current all +``` -The easyest way to compile and run the code is to use the prepared docker images. -Therefore, 1. install *docker*, 2. clone the project *dune-docker*, 3. create the -image `dune:git`, 4. run this docker image with interactive shell. -(See also the `README.md` in the *dune-docker* project for details). +The `dunecontrol` script searches for the required +(and suggested) dune modules this library depends on. These include: +- [dune-common](https://gitlab.dune-project.org/core/dune-common) +- [dune-geometry](https://gitlab.dune-project.org/core/dune-geometry) +- [dune-grid](https://gitlab.dune-project.org/core/dune-grid) +- [dune-localfunctions](https://gitlab.dune-project.org/core/dune-localfunctions) +- [dune-typetree](https://gitlab.dune-project.org/staging/dune-typetree) +- [dune-functions](https://gitlab.dune-project.org/staging/dune-functions) -Prepare for installation ------------------------- +(See the file `dune.module` for an up-to-date list of dependencies). The dune modules +can be obtained from https://gitlab.dune-project.org and need to be found in a +subdirectory of `DUNE_CONTROL_PATH`. See also https://dune-project.org/doc/installation +for details about the installation of dune modules. -In order to resolve external dependencies, run the script `contrib/ci-setup`. This -will download the latest MTL4 library (and maybe more). +Additionally we require the following libraries to be found: +- [MTL4](https://gitlab.math.tu-dresden.de/spraetor/mtl4) (use this fork to get up-to-date changes) +- [SuiteSparse](http://faculty.cse.tamu.edu/davis/suitesparse.html) (optional) +- libalberta >= 3.0 (For Alberta-Grids) -Compile and link the library and examples ------------------------------------------ +And a compiler that supports the C++14 standard, e.g. g++ >= 4.9 and clang >= 3.6, and cmake >= 3.1. -Simply run +If your MTL4 installation is not found by default, you have to specify the path, +where the file `MTLConfig.cmake` is found, here called `MTL_ROOT`. Then simply use +`dunecontrol` to configure and `cmake` to build: ``` -dunecontrol --opts=/duneci/opts.gcc --current all +CMAKE_FLAGS="-DMTL_DIR:PATH=[MTL_ROOT]" dunecontrol --current configure +cmake --build build-cmake ``` -to build the library and to compile and link the examples from the `src/` directory. \ No newline at end of file +This compiles the library and all examples in the `src/` directory. diff --git a/doc/Installation.md b/doc/Installation.md new file mode 100644 index 0000000000000000000000000000000000000000..2e2c411c103b4cac8236868d30144d9d76917758 --- /dev/null +++ b/doc/Installation.md @@ -0,0 +1,42 @@ +Installation instructions +========================= +We provide a *cmake*-based configuration and use the `dunecontrol` build system. +Simply run + +``` +dunecontrol --current all +``` + +The `dunecontrol` script searches for the required +(and suggested) dune modules this library depends on. These include: +- [dune-common](https://gitlab.dune-project.org/core/dune-common) +- [dune-geometry](https://gitlab.dune-project.org/core/dune-geometry) +- [dune-grid](https://gitlab.dune-project.org/core/dune-grid) +- [dune-localfunctions](https://gitlab.dune-project.org/core/dune-localfunctions) +- [dune-typetree](https://gitlab.dune-project.org/staging/dune-typetree) +- [dune-functions](https://gitlab.dune-project.org/staging/dune-functions) + +(See the file `dune.module` for an up-to-date list of dependencies). The dune modules +can be obtained from https://gitlab.dune-project.org and need to be found in a +subdirectory of `DUNE_CONTROL_PATH`. See also https://dune-project.org/doc/installation +for details about the installation of dune modules. + +Additionally we require the following libraries to be found: +- [MTL4](https://gitlab.math.tu-dresden.de/spraetor/mtl4) (use this fork to get up-to-date changes) +- [Boost](http://www.boost.org) >= 1.40 +- [SuiteSparse](http://faculty.cse.tamu.edu/davis/suitesparse.html) (optional) +- libalberta >= 3.0 (For Alberta-Grids) + +And a compiler that supports the C++14 standard, e.g. `g++` >= 4.9 and `clang` >= 3.6, +and `cmake` >= 3.1. + +If your MTL4 installation is not found by default, you have to specify the path, +where the file `MTLConfig.cmake` is found, here called `MTL_ROOT`. Then simply use +`dunecontrol` to configure and `cmake` to build: + +``` +CMAKE_FLAGS="-DMTL_DIR:PATH=[MTL_ROOT]" dunecontrol --current configure +cmake --build build-cmake +``` + +This compiles the library and all examples in the `src/` directory. diff --git a/doc/Mainpage.md b/doc/Mainpage.md new file mode 100644 index 0000000000000000000000000000000000000000..3797679e04930f9431853114358495e70ddecc13 --- /dev/null +++ b/doc/Mainpage.md @@ -0,0 +1,133 @@ +AMDiS {#mainpage} +===== +The *Adaptive Multi-Dimensional Simulation Toolbox* (AMDiS) is implemented as a +discretization module on top of the [Dune](https://dune-project.org) framework. + +Example +------- + +An AMDiS program consists of three main incredients: +1. A Problem class that holds all information necessary for assembling a linear + system, see \ref ProblemStat. +2. Operators describing the (bi)linear-form of your PDE, see \ref operators. +3. Adaption-modules for the time- and space adaptive solution of the problem, see \ref Adaption. + +**Poisson equation:** + +The most simple elliptic PDE is the Poisson equation: +\f{eqnarray*}{ + -\Delta u &=& f(x),\quad\mbox{ in }\Omega \\ + u &=& g(x),\quad\mbox{ on }\partial\Omega +\f} +where \f$ f(x) \f$ and \f$ g(x) \f$ are parameters describing the volume and +boundary forces of the problem. + +The corresponding weak form of the equation reads: +\f[ + \langle \nabla v, \nabla u\rangle_\Omega = (f(x)\,v)_\Omega,\quad\forall v\in V_0 +\f] +with \f$ u\in V_g \f$. + +Thus, we need to define a grid (discretization of \f$ \Omega \f$) and a finite +element space (discretization of \f$ V_0 \f$ and \f$ V_g \f$). This needs to be +provided as `Traits` parameter in the ProblemStat class: + +~~~~~~~~~~~~~~~{.cpp} +using Grid = Dune::AlbertaGrid<AMDIS_DIM, AMDIS_DOW>; +using Traits = LagrangeBasis<Grid::LeafGridView, 1>; +~~~~~~~~~~~~~~~ + +This defines and `AlbertaGrid` as grid and a Lagrange Finite-Element space with +local polynomial degree 1 on the elements. + +All AMDiS programs start with initialization of the library, using `AMDiS::init` + +~~~~~~~~~~~~~~~{.cpp} +using namespace AMDiS; +int main(int argc, char** argv) +{ + AMDiS::init(argc, argv); + + ProblemStat<Traits> prob("name"); +~~~~~~~~~~~~~~~ + +The Problem class is initialized with a name, that is used as identifier in the +parameter files. In order to initialize the Finite-Element space, the grid and +all other parts of the problem class, call `initialize(Flag)` where `Flag` +specifies what to initialize. For now, we initialize everything: `INIT_ALL`: + +~~~~~~~~~~~~~~~{.cpp} +prob.initialize(INIT_ALL); +~~~~~~~~~~~~~~~ + +Operators specify the (bi-)linear-form and the coefficient function in the term, +see \ref operators for a list of possible types. The bilinear-form in the Poisson +equation consists of second-order term with coefficitn = 1 and the linear-form +includes the function \f$ f(x)=-1 \f$: + +~~~~~~~~~~~~~~~{.cpp} +auto opL = makeOperator(tag::gradtest_gradtrial{}, 1.0); +prob.addMatrixOperator(opL, 0, 0); + +auto opF = makeOperator(tag::test{}, [](auto const& x) { return -1.0; }, 0); +prob.addVectorOperator(opF, 0); +~~~~~~~~~~~~~~~ + +Boundary conditions, in the example above a Dirichlet condition, is specified by +defining a predicate for the boundary \f$ \partial\Omega \f$ and the values on the +boundary \f$ g(x) = 0 \f$: + +~~~~~~~~~~~~~~~{.cpp} +auto predicate = [](auto const& x){ return x[0] < 1.e-8 || x[1] < 1.e-8; }; +prob.addDirichletBC(predicate, 0, 0, 0.0); +~~~~~~~~~~~~~~~ + +The final step is the assembling and solution of the linear system. (Maybe including +grid adaption). This is realized using an \ref AdaptStationary class: + +~~~~~~~~~~~~~~~{.cpp} +AdaptInfo adaptInfo("adapt"); +AdaptStationary adapt("adapt", prob); +adapt.adapt(); // assemble and solve +~~~~~~~~~~~~~~~ + +Finally, finish the AMDiS program with `AMDiS::finish()`. + +In complete program then reads: +~~~~~~~~~~~~~~~{.cpp} +#include <dune/amdis/AMDiS.hpp> +#include <dune/amdis/AdaptInfo.hpp> +#include <dune/amdis/AdaptStationary.hpp> +#include <dune/amdis/ProblemStat.hpp> + +using namespace AMDiS; + +using Grid = Dune::AlbertaGrid<AMDIS_DIM, AMDIS_DOW>; +using Traits = LagrangeBasis<Grid::LeafGridView, 1>; + +int main(int argc, char** argv) +{ + AMDiS::init(argc, argv); + + ProblemStat<Traits> prob("poisson"); + prob.initialize(INIT_ALL); + + auto opL = makeOperator(tag::gradtest_gradtrial{}, 1.0); + prob.addMatrixOperator(opL, 0, 0); + + auto opF = makeOperator(tag::test{}, [](auto const& x) { return -1.0; }, 0); + prob.addVectorOperator(opF, 0); + + // set boundary condition + auto predicate = [](auto const& x){ return x[0] < 1.e-8 || x[1] < 1.e-8; }; + prob.addDirichletBC(predicate, 0, 0, 0.0); + + // assemble and solve + AdaptInfo adaptInfo("adapt"); + AdaptStationary adapt("adapt", prob); + adapt.adapt(); + + AMDiS::finalize(); + return 0; +} +~~~~~~~~~~~~~~~ \ No newline at end of file diff --git a/doc/doxygen/Doxylocal b/doc/doxygen/Doxylocal index b014153bf1f0ab42db612949c0dacccda9938883..52404d1cc11a158c5089cbf5dbada4d5dd679b86 100644 --- a/doc/doxygen/Doxylocal +++ b/doc/doxygen/Doxylocal @@ -2,7 +2,8 @@ # please us '+=' to add file/directories to the lists FILE_PATTERNS += *.hpp \ - *.cpp + *.cpp \ + *.md HIDE_SCOPE_NAMES = YES HIDE_UNDOC_CLASSES = NO @@ -33,7 +34,8 @@ INPUT += @top_srcdir@/dune/amdis \ @top_srcdir@/dune/amdis/linear_algebra \ @top_srcdir@/dune/amdis/linear_algebra/mtl \ @top_srcdir@/dune/amdis/operations \ - @top_srcdir@/dune/amdis/utility + @top_srcdir@/dune/amdis/utility \ + @top_srcdir@/doc # see e.g. dune-grid for the examples of mainpage and modules #INPUT += @srcdir@/mainpage \ # @srcdir@/modules diff --git a/dune-amdis.pc.in b/dune-amdis.pc.in index e3186b50e9df3066a9f23117efc1a512fb586d08..c41ceecce7b6d78dbf18a6e44596979726328989 100644 --- a/dune-amdis.pc.in +++ b/dune-amdis.pc.in @@ -10,7 +10,7 @@ Name: @PACKAGE_NAME@ Version: @VERSION@ Description: AMDiS dune-module URL: https://gitlab.math.tu-dresden.de/spraetor/dune-amdis -Requires: dune-common dune-geometry dune-localfunctions dune-istl dune-typetree dune-grid dune-functions -Suggests: dune-uggrid dune-alugrid +Requires: dune-common dune-geometry dune-localfunctions dune-typetree dune-grid dune-functions +Suggests: dune-uggrid dune-alugrid dune-foamgrid Libs: -L${libdir} Cflags: -I${includedir} diff --git a/dune.module b/dune.module index dae9337d4ed1ea698559bd0ea485b196e99219cc..7f0fcd8f05478fe6f00fd3ce060e5572568fd4c7 100644 --- a/dune.module +++ b/dune.module @@ -7,5 +7,5 @@ Module: dune-amdis Version: 0.1 Maintainer: simon.praetorius@tu-dresden.de #depending on -Depends: dune-common dune-geometry dune-localfunctions dune-istl dune-typetree dune-grid dune-functions -Suggests: dune-uggrid dune-alugrid +Depends: dune-common dune-geometry dune-localfunctions dune-typetree dune-grid dune-functions +Suggests: dune-uggrid dune-alugrid dune-foamgrid diff --git a/dune/amdis/gridfunctions/ConstantGridFunction.hpp b/dune/amdis/gridfunctions/ConstantGridFunction.hpp index faca6ede43e79890c9cf5429126c9798e7437e70..c09ab30ce81ec1554defc91a48cf5d2d07205ebc 100644 --- a/dune/amdis/gridfunctions/ConstantGridFunction.hpp +++ b/dune/amdis/gridfunctions/ConstantGridFunction.hpp @@ -150,6 +150,9 @@ namespace AMDiS } // end namespace Definition + /// \brief Concepts that is true for all ''simple'' types that can be + /// converted automatically to a GridFunction, e.g. arithmetic types, + /// FieldVectors, and `std::reference_wrapper`. template <class T> constexpr bool ConstantToGridFunction = Definition::ConstantToGridFunction<T>::value; diff --git a/dune/amdis/gridfunctions/GridFunctionConcepts.hpp b/dune/amdis/gridfunctions/GridFunctionConcepts.hpp index 648bad47729c5c1fafaca2ef6e9a41006c926b06..b4ae379f1a209ac5eee857ad095622b290948bbe 100644 --- a/dune/amdis/gridfunctions/GridFunctionConcepts.hpp +++ b/dune/amdis/gridfunctions/GridFunctionConcepts.hpp @@ -75,24 +75,32 @@ namespace AMDiS } // end namespace Definition + /// \brief GridFunction F has free function `localFunction(F)` template <class F> constexpr bool HasLocalFunction = models<Definition::HasLocalFunction(F)>; + /// \brief GridFunction F has free function `derivative(F)` template <class F> constexpr bool HasDerivative = models<Definition::HasDerivative(F)>; + /// \brief GridFunction F has free function `derivative(localFunction(F))` template <class F> constexpr bool HasLocalFunctionDerivative = models<Definition::HasLocalFunctionDerivative(F)>; + /// \brief GridFunction F has free function `order(localFunction(F))` template <class F> constexpr bool HasLocalFunctionOrder = models<Definition::HasLocalFunctionOrder(F)>; + /// \brief Functor F has free function `partial(F,_0)` template <class F> constexpr bool HasPartial = models<Definition::HasPartial(F)>; + /// \brief Functor F has free function `order(F)` template <class F> constexpr bool HasOrder = models<Definition::HasOrder(F)>; + + /// \brief Functor F is collable with GlobalCoordinates `F(Dune::FieldVector<double,DOW>)` #ifndef AMDIS_DOW template <class F> constexpr bool CallableDomain = @@ -103,11 +111,14 @@ namespace AMDiS Definition::CallableDow<F, AMDIS_DOW>; #endif - // types that is a GridFunction + /// \brief GridFunction GF is a Type that has LocalFunction and provides some + /// typedefs for `Domain`, `Range`, and `EntitySet`. template <class GF> constexpr bool GridFunction = HasLocalFunction<GF> && models<Definition::HasGridFunctionTypes(GF)>; + /// \brief Concept is fulfilled, if at least one of the massed Expressions + /// can be converted to a GridFunction, or is already a GridFunction. template <class... GFs> constexpr bool AnyGridFunction = any_of_v<GridFunction<std::decay_t<GFs>>...> ||