hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2024-03-06T08:43:00+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/246New generated Stokes operators2024-03-06T08:43:00+01:00Nils KohlNew generated Stokes operatorsThis issue shall document and **discuss** the introduction of the Stokes composite operators that are built from the new generated operators.
Also **point out if I made a mistake** and feel free to correct this description.
## List of S...This issue shall document and **discuss** the introduction of the Stokes composite operators that are built from the new generated operators.
Also **point out if I made a mistake** and feel free to correct this description.
## List of Stokes operators
It seems(?) that we are particularly interested in three types of Stokes operators, particularly differing in the momentum terms.
Let
```math
K = \begin{bmatrix}
A & B^T \\
B & 0
\end{bmatrix}
```
be the discrete Stokes operator for a $\mathbb{P}_2-\mathbb{P}_1$ Taylor-Hood discretization.
The operators differ in the way the $A$ block is defined. Let's summarize.
| Proposed name (prefix) | Strong form of momentum term ("velocity part") | Weak form that defines $A$ |
| ------ | ------ | ------ |
| `P2P1StokesConstant` | $- \Delta u$ | $\displaystyle\int_\Omega \nabla u : \nabla v$ |
| `P2P1StokesEpsilon` | $\displaystyle- \nabla \cdot \Big(2 \mu \varepsilon(u)\Big)$ | $\displaystyle\int_\Omega 2 \mu \Big(\varepsilon(u) : \varepsilon(v)\Big)$ |
| `P2P1StokesFull` | $\displaystyle - \nabla \cdot \Big( 2 \mu \varepsilon(u) \Big) - \frac{2}{\mathrm{dim}} \nabla (\nabla \cdot u)$ | $\displaystyle\int_\Omega 2 \mu \Big(\varepsilon(u) : \varepsilon(v)\Big) - \frac{2}{\mathrm{dim}} (\nabla \cdot u) \cdot (\nabla \cdot v)$
where $\varepsilon(w) = \frac{1}{2} (\nabla w + (\nabla w)^T)$.
$\mu = \mu(x)$ will eventually be a scalar finite element function (in $\mathbb{P}_2$) that is supplied by the user.
## Possible file structure
I propose the following structure - **open to suggestions**.
```
hyteg/src/
- hyteg/
- terraneo/
- ...
- hyteg_operators/ # submodule with generated operators
- hyteg_operators_composites/ # new module
- stokes/
- viscousblock/
- P2ViscousBlockLaplaceOperator.*pp
- P2ViscousBlockEpsilonOperator.*pp
- P2ViscousBlockFullOperator.*pp
- divergence/
- P2VectortoP1DivergenceOperator.*pp
- gradient/
- P1toP2VectorGradientOperator.*pp
- P2P1StokesConstantOperator.*pp
- P2P1StokesEpsilonOperator.*pp
- P2P1StokesFullOperator.*pp
- ...
```
## Blending
For each relevant blending map, additional operators will be added to the respective files. For instance
```cpp
// P2P1StokesEpsilonOperator.hpp
class P2P1StokesEpsilonOperator { ... };
class P2P1StokesEpsilonIcosahedralShellMapOperator { ... };
```
## Some notes
* I am not sure yet which quadrature rules to choose for the blending cases. For now I chose rules that integrate degree 3 polynomials exactly for blending, and degree 2 polynomials without blending (the latter should be sufficient to maintain convergence order(?)). But we may want to discuss this.
* The new composites shall _only_ use/depend on the newly generated operators and never introduce any of the existing constant stencil ops, elementwise ops etc. If something is missing, we should adapt the HFG.
* Lumped and diagonal operators are already in the making. Those are needed for all sorts of preconditioners.
* I currently only consider Taylor-Hood-style operators. Stabilized $\mathbb{P}_1-\mathbb{P}_1$ operators should be straightforward to generate, too.
* In the future, we want to enable the HFG to generate the vector-operators directly such that they do not have to be composed manually. This will likely remove the need for all operators in the subdirectories `viscousblock`, `gradient`, `divergence`, etc. But for starters, we will probably go with the composed versions.
## Checklist
- [x] generate scalar block operators
- [x] compile composites for viscous blocks (!710)
- [x] compile div and grad blocks (!710)
- [x] compile Stokes operators (!710)
- [x] tests (!710)
- [ ] compile/implement diagonal operators to use preconditioners (moved to #250)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/156Building blocks for mantle convection simulations for models with variable vi...2022-02-24T11:34:00+01:00Marcus MohrBuilding blocks for mantle convection simulations for models with variable viscosity and anelastic approximationHi,
in order to run mantle convection models on a thick spherical shell with blending and variable viscosity and the generalised mass conservation equation of the (truncated) anelastic approximation some building blocks are still missin...Hi,
in order to run mantle convection models on a thick spherical shell with blending and variable viscosity and the generalised mass conservation equation of the (truncated) anelastic approximation some building blocks are still missing. Especially in such models we need the
- **Epsilon Operator** given by
```math
\mathcal{A}(\vec{u}) = \text{div}\left[\mu\left(\text{grad}(\vec{u})+ \text{grad}(\vec{u})^T\right)
\right]
```
- and the **Full Viscous Operator** given by
```math
\mathcal{A}(\vec{u}) = \text{div}\left[\mu\left(\text{grad}(\vec{u})+ \text{grad}(\vec{u})^T\right)
\right] - \frac{2}{3} \text{grad}\left(\mu\,\text{div}\vec{u}\right)
```
where $`\mu`$ is the variable kinematic viscosity.
Components that need implementing are:
1. *Epsilon operators* that make use of the already available HyTeG forms which support blending and/or a callback function for viscosity, these are
- ```p[12]_epsiloncc_*_*_affine_q2```
- ```p[12]_epsiloncc_*_*_blending_q2```
- ```p[12]_epsilonvar_*_*_affine_q2```
- ```p[12]_epsilonvar_*_*_blending_q2```
currently these forms seem not to be used anywhere. Note that also of the corresponding FEniCS forms only the 2D version ```p1_stokes_epsilon``` seems to show up in an operator, but neither the ``p2`` variant nor the 3D versions ```p[12]_stokes_epsilon_tet```.
1. Different forms for the full viscous operator
1. Operators allowing to use the forms for the full viscous operator
1. Tests for the new forms and for the new operators
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/169Boundary Conditions and Constructors of Function classes2021-12-20T15:32:56+01:00Marcus MohrBoundary Conditions and Constructors of Function classesHi,
I just noted a small inconsistency in the constructors of the `P*VectorFunction`s compared to those of the scalar functions. All of
- P1Function
- P2Function
- EdgeDoFFunction
- FaceDoFFunction
provide a constructor version that a...Hi,
I just noted a small inconsistency in the constructors of the `P*VectorFunction`s compared to those of the scalar functions. All of
- P1Function
- P2Function
- EdgeDoFFunction
- FaceDoFFunction
provide a constructor version that allows to set a `BoundaryCondition`. The constructor which does not allow this, in turn delegates to the other one using our default variant `BoundaryCondition::create0123BC()` to generate a B.C. object.
- P1VectorFunction
- P2VectorFunction
both currently provide only a single constructor that
- does not allow to set the boundary condition
- and also does not set the default
IMHO we should fix this by extending the two classes.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/97Indexing of local macro-edges is inconsistent comparing 2D vs 3D2019-08-29T08:57:15+02:00Nils KohlIndexing of local macro-edges is inconsistent comparing 2D vs 3DThe local macro-edges of a macro-face are not indexed in the same way they are on the bottom face of a macro-cell.The local macro-edges of a macro-face are not indexed in the same way they are on the bottom face of a macro-cell.Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/64Definition of intergrid transfer operators in own classes to flexibly pass th...2018-06-11T17:07:12+02:00Dominik BartuschatDefinition of intergrid transfer operators in own classes to flexibly pass these operators as template arguments for multigrid solverCurrently all prolongation and restict operators are implemented in the corresponding P?Function.hpp and PrimiveDoFFunction.hpp. At a later stage, one might want to flexibly pass these transfer operators to the MultigridSolver as templat...Currently all prolongation and restict operators are implemented in the corresponding P?Function.hpp and PrimiveDoFFunction.hpp. At a later stage, one might want to flexibly pass these transfer operators to the MultigridSolver as template argument. Therefore it might be useful to specifically design own classes for these operators. Another advantage would be that the functions can be moved outside the different (already quite long) functionSpace and DoFFunction files.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/27Implement cells (3D primitives) on topology side2017-09-04T15:31:57+02:00Nils KohlImplement cells (3D primitives) on topology sideIn order to allow 3D simulations, apart from extensions to the function spaces we need to
* [x] read in 3D meshes
* [x] setup the SetupStorage accordingly
* [x] setup the distributed storage accordingly
* [x] implement all getters / ...In order to allow 3D simulations, apart from extensions to the function spaces we need to
* [x] read in 3D meshes
* [x] setup the SetupStorage accordingly
* [x] setup the distributed storage accordingly
* [x] implement all getters / setters that are available for 2D
* [x] test topology features for 3D (e.g. data handling, buffered communication, data migration, load balancing)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/13Removing walberla app builds on windows2017-08-30T13:41:24+02:00Nils KohlRemoving walberla app builds on windowsIt looks like the tinyhhg pipeline builds walberla apps on Windows.
```
27>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\CL.exe /c /I"C:\cygwin64\home\build\builds\terraneo\tinyhhg\extern\fmt-3.0.1...It looks like the tinyhhg pipeline builds walberla apps on Windows.
```
27>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\CL.exe /c /I"C:\cygwin64\home\build\builds\terraneo\tinyhhg\extern\fmt-3.0.1" /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\src /I"C:\Boost\include\boost-1_63" /I"C:\Program Files (x86)\Microsoft SDKs\MPI\include" /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\build\walberla\src /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\walberla\src /nologo /W4 /WX- /MP /O2 /Ob2 /D WIN32 /D _WINDOWS /D NDEBUG /D NOMINMAX /D _WIN32_WINNT=0x501 /D WINVER=0x501 /D _CRT_SECURE_NO_WARNINGS /D _SCL_SECURE_NO_WARNINGS /D BOOST_ALL_NO_LIB /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"SchaeferTurek.dir\Release\\" /Fd"SchaeferTurek.dir\Release\vc140.pdb" /Gd /TP /wd4127 /wd4512 /wd4913 /wd4702 /wd4505 /wd4503 /errorReport:queue -bigobj C:\cygwin64\home\build\builds\terraneo\tinyhhg\walberla\apps\benchmarks\SchaeferTurek\SchaeferTurek.cpp
```Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/23Allow metadata in MeshInfo primitives2017-08-30T10:34:58+02:00Nils KohlAllow metadata in MeshInfo primitivesNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/15Build doxygen documentation via CI2017-07-26T17:12:51+02:00Nils KohlBuild doxygen documentation via CIIt would be nice to be able to access the doxygen documentation from a Pipeline as an artifact.It would be nice to be able to access the doxygen documentation from a Pipeline as an artifact.Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.de