hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2024-09-30T13:52:17+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/830Add option to utilise reference temperature profiles in TerraNeo2024-09-30T13:52:17+02:00Eugenio D'AscoliAdd option to utilise reference temperature profiles in TerraNeoA reference temperature profile can be provided within the parameters.prm file.
If a profile is provided, the application will use this profile as the reference temperature profile throughout the mantle.
The temperature deviations will h...A reference temperature profile can be provided within the parameters.prm file.
If a profile is provided, the application will use this profile as the reference temperature profile throughout the mantle.
The temperature deviations will henceforth be estimated with respect to this profile.
The profile has to be in .json format with one entry holding the key "Radius (m)" and the corresponding
data values in descending order starting from the surface.
The second entry must be the temperature [K].Eugenio D'AscoliEugenio D'Ascolihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/834[Rebased] Radially aligned annulus and icosahedral shell maps.2024-09-25T09:58:13+02:00Nils Kohl[Rebased] Radially aligned annulus and icosahedral shell maps.Rebased !829 on master after merging !828.
-----
Re-introduced from 7bc4be0bc8f1e3a9c401b1e487f5622ad7845592 and parents (see !792).
-----
Opposed to their "unaligned" counterparts, the new maps align micro-vertices radially along ra...Rebased !829 on master after merging !828.
-----
Re-introduced from 7bc4be0bc8f1e3a9c401b1e487f5622ad7845592 and parents (see !792).
-----
Opposed to their "unaligned" counterparts, the new maps align micro-vertices radially along rays from the origin.
These new maps are not well tested in combination with operators, but the forward mapping should be working and usable with the implementation of parametric maps via the MicroMesh class (example in `apps/show_mesh.cpp`).Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/829Draft: Radially aligned annulus and icosahedral shell maps.2024-09-24T15:25:42+02:00Nils KohlDraft: Radially aligned annulus and icosahedral shell maps.Should be rebased onto master after !828 is merged.
-----
Re-introduced from 7bc4be0bc8f1e3a9c401b1e487f5622ad7845592 and parents (see !792).
-----
Opposed to their "unaligned" counterparts, the new maps align micro-vertices radially...Should be rebased onto master after !828 is merged.
-----
Re-introduced from 7bc4be0bc8f1e3a9c401b1e487f5622ad7845592 and parents (see !792).
-----
Opposed to their "unaligned" counterparts, the new maps align micro-vertices radially along rays from the origin.
These new maps are not well tested in combination with operators, but the forward mapping should be working and usable with the implementation of parametric maps via the MicroMesh class.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/822Allow exporting a refined mesh from HyTeG2024-09-24T11:04:01+02:00Marcus MohrAllow exporting a refined mesh from HyTeGIn the last developer meeting the funtionality for exporting a refined mesh from HyTeG to import into other FEM libraries to run comparisons was requested. This MR provides this functionality.
The `gmsh::exportRefinedMesh()` function ge...In the last developer meeting the funtionality for exporting a refined mesh from HyTeG to import into other FEM libraries to run comparisons was requested. This MR provides this functionality.
The `gmsh::exportRefinedMesh()` function generates a minimal MSH4.1 file containing the three sections
- **MeshFormat**
- **Nodes**
- **Elements**
These are enough to describe the plain mesh. Some applications might also require an **Entities** section. We could generate that, too, if need be. The current implementation uses the macro-primitives as entities and we could base the information in an Entities section also on these.
The implementation seems to work, as one can import the generated files into Gmsh or reimport them into HyTeG.![Gmsh-Annulus](/uploads/dd9bb125c0357010ae91e8aa432b5bb2/Gmsh-Annulus.png)![Gmsh-ThickSphericalShell](/uploads/49b363d10df29b91065dc626263c42f2/Gmsh-ThickSphericalShell.png)Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/821[Rebased] MicroMesh & iso-/super-/sub-parametric elements2024-09-18T14:12:03+02:00Nils Kohl[Rebased] MicroMesh & iso-/super-/sub-parametric elements> Rebased. Old MR: !814
# Overview
This MR introduces utilities to work with iso-, sub-, and super-parametric meshes.
Mainly it enables/simplifies working with meshes the node-positions of which are specified as finite element functi...> Rebased. Old MR: !814
# Overview
This MR introduces utilities to work with iso-, sub-, and super-parametric meshes.
Mainly it enables/simplifies working with meshes the node-positions of which are specified as finite element functions.
Instead of using the blending function feature, the geometry can be interpolated into a (vector-valued) P1 or P2 space.
Using the HOG, the local Jacobians can be computed straightforwardly by evaluation of the gradients of the shape functions (see https://i10git.cs.fau.de/hyteg/hog/-/merge_requests/24).
Functions to generate appropriate volume meshes from either surface meshes or analytical descriptions of curved geometries are not yet included in this MR.
For more details see docstring of `MicroMesh`.
# Concrete changes
* `MicroMesh` class and several centralized functions to compute node positions
* corresponding VTK output adaptions
* some tests
* new operators via hyteg_operators update
# TODOs
## Necessary
- [x] generate isoparametric operators necessary for the tests and update hyteg-operators afterwards
- [ ] proper VTK test before merging this (specifically, #278 would be very nice)
## Nice to have / next steps
- proper, stable mesh improvement
- semi-automated meshing from surface representations (e.g., via OpenMesh or gmsh)
- tutorial
- more operators
# Images
## 2D, piecewise quadratic mesh (P2, level 3)
(left: coarse mesh, middle: projected, right: projected and corrected with diffusion)
![curved_mesh_2D](/uploads/dfac15b0a63760d1264fbc4b6e46d4c3/curved_mesh_2D.png)
## 3D, piecewise quadratic mesh (P2, level 3)
(left: coarse mesh, middle: projected, right: projected with edges)
![curved_mesh_3D](/uploads/71f2d2ee2fb4e84b0a328bb90ecfc760/curved_mesh_3D.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/814Draft: MicroMesh & iso-/super-/sub-parametric elements2024-09-18T14:11:49+02:00Nils KohlDraft: MicroMesh & iso-/super-/sub-parametric elements# Overview
This MR introduces utilities to work with iso-, sub-, and super-parametric meshes.
Mainly it enables/simplifies working with meshes the node-positions of which are specified as finite element functions.
Instead of using the ...# Overview
This MR introduces utilities to work with iso-, sub-, and super-parametric meshes.
Mainly it enables/simplifies working with meshes the node-positions of which are specified as finite element functions.
Instead of using the blending function feature, the geometry can be interpolated into a (vector-valued) P1 or P2 space.
Using the HOG, the local Jacobians can be computed straightforwardly by evaluation of the gradients of the shape functions (see https://i10git.cs.fau.de/hyteg/hog/-/merge_requests/24).
Functions to generate appropriate volume meshes from either surface meshes or analytical descriptions of curved geometries are not yet included in this MR.
For more details see docstring of `MicroMesh`.
# Concrete changes
* `MicroMesh` class and several centralized functions to compute node positions
* corresponding VTK output adaptions
* some tests
# TODOs
## Necessary
- [x] generate isoparametric operators necessary for the tests and update hyteg-operators afterwards
- [ ] proper VTK test before merging this (specifically, #278 would be very nice)
## Nice to have / next steps
- proper, stable mesh improvement
- semi-automated meshing from surface representations (e.g., via OpenMesh or gmsh)
- tutorial
- more operators
# Images
## 2D, piecewise quadratic mesh (P2, level 3)
(left: coarse mesh, middle: projected, right: projected and corrected with diffusion)
![curved_mesh_2D](/uploads/dfac15b0a63760d1264fbc4b6e46d4c3/curved_mesh_2D.png)
## 3D, piecewise quadratic mesh (P2, level 3)
(left: coarse mesh, middle: projected, right: projected with edges)
![curved_mesh_3D](/uploads/71f2d2ee2fb4e84b0a328bb90ecfc760/curved_mesh_3D.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/801Add a reader for Gmsh files in MSH 4.1 format2024-09-12T15:16:31+02:00Marcus MohrAdd a reader for Gmsh files in MSH 4.1 formatAs explained in #271 the MSH2.2 format is quite out-dated. However, it is currently the only mesh format we can import with HyTeG. This MR changes this by implementing a reader for the current MSH4.1 format. Doing so it fixes #271.
Addi...As explained in #271 the MSH2.2 format is quite out-dated. However, it is currently the only mesh format we can import with HyTeG. This MR changes this by implementing a reader for the current MSH4.1 format. Doing so it fixes #271.
Additionally the MR also addresses #275 by allowing to consistently using the physical tags in the mesh-file to set the primitives boundary flags. An example is given below which was generated with ParaView from the output of the `show_mesh` app for the `two-blocks.msh` file. In the file the two rectangular blocks have different physical tags, as have the vertices and edges for the left part, those in the right part and the two vertices and edge forming the interface between the two blocks. The images demonstrate that the reader correctly sets these values for all primitives present in the *Nodes* and *Elements* section of the file and also correctly deduces the flags for the derived primitives. In our case here these are the edges inside the two blocks.
![Edges](/uploads/57bb9e203686a5a4af529df7322ee37b/Edges.png)![Edges+Vertices](/uploads/dd8fa5e3e18e50d00bcc8ef86b0a66f8/Edges+Vertices.png)![Edges+Vertices+Faces](/uploads/c785e2d0feb4180b9212ff907c364ae4/Edges+Vertices+Faces.png)
I have not added a specific test for the new reader. Instead the MR replaces several 2D and 3D meshes used in the testsuite by versions in MSH4.1 format.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/803Draft: Implement functionality to update non-dimensional numbers (e.g. Di, Ra, Grueneisen) based on user defined radial profiles2024-08-09T16:16:50+02:00Eugenio D'AscoliDraft: Implement functionality to update non-dimensional numbers (e.g. Di, Ra, Grueneisen) based on user defined radial profilesUsers can provide radial profiles for the calculation of non-dimensional numbers such as the
Grueneisen parameter, thermal expansivity or specific heat capacity.
If radial profile values lie in between given data points a linear interpo...Users can provide radial profiles for the calculation of non-dimensional numbers such as the
Grueneisen parameter, thermal expansivity or specific heat capacity.
If radial profile values lie in between given data points a linear interpolation will be
performed to estimate the radial profile value at the given location.
If a radial profile is used the non-dimensional numbers will be updated during runtime according to the
corresponding radial profile.
These radial profiles have to be in .json format with one entry for the radius holding the key-argument: "Radius (m)".
The radius entry must be sorted descending from surface (m) to CMB (m)
The second entry will hence be derived as data value entry.
A check for min and max radii of the radial profile will ensure that only reasonable profiles can be utilised (r_max <= r_surface and r_min >= r_CMB).Eugenio D'AscoliEugenio D'Ascolihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/798Add a prependHyTeGMeshDir() function2024-08-08T11:42:52+02:00Marcus MohrAdd a prependHyTeGMeshDir() functionAs discussed internally we would like to make opening "internal" mesh files in tests and tutorials resilient against re-location of source
code files.
This MR suggest a solution by adding a HYTEG_MESH_DIR macro that stores the absolute ...As discussed internally we would like to make opening "internal" mesh files in tests and tutorials resilient against re-location of source
code files.
This MR suggest a solution by adding a HYTEG_MESH_DIR macro that stores the absolute path to "data/mesh" inside the build directory. Additionally it adds a free function prependHyTeGMeshDir() that can be used to prepend this path to a filename or relative path.https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/706First version of an abstract reduce function2024-06-13T12:51:42+02:00Dominik Thoennesdominik.thoennes@fau.deFirst version of an abstract reduce functionThis MR introduces an abstract reduce function which could replace e.g. the `getMaxValue` function.
The `std::function` might reduce the runtime of the function.
I made some benchmarks with the `allGather` version of this.
Here is the ...This MR introduces an abstract reduce function which could replace e.g. the `getMaxValue` function.
The `std::function` might reduce the runtime of the function.
I made some benchmarks with the `allGather` version of this.
Here is the average runtime in seconds per process for a very simple benchmark which performs the getMaxValue **1000 times** with 4608 processes (64 nodes * 72 cores).
Note: l
| | getMaxValue | w.o. MPI | | abstract getMaxValue | w.o. MPI |
|------------|-------------|----------|---|----------------------|----------|
| first run | 0.20 s | 0.12 s | | 0.63 s | 0.17 s |
| second run | 0.17 s | 0.12 s | | 0.61 s | 0.17 s |
When using allReduce instead of allGather these are numbers for commit 6e12c653. again **1000 times** with 4608 processes (64 nodes * 72 cores)
| | getMaxValue | w.o. MPI | | abstract getMaxValue | w.o. MPI |
|------------|-------------|----------|---|----------------------|----------|
| first run | 0.18 s | 0.11 s | | 0.22 s | 0.14 s |
| second run | 0.20 s | 0.11 s | | 0.21 s | 0.14 s |https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/759Radial shell output, radial shell IDs, duplicate DoF counting2024-06-12T20:52:44+02:00Nils KohlRadial shell output, radial shell IDs, duplicate DoF countingRebased and extended from !753.
# Content
This MR deals with radial output and some other features.
Contributions:
- fixes and refactoring of the computation of radial shells and layers for the refined, radially equidistant Icosahedr...Rebased and extended from !753.
# Content
This MR deals with radial output and some other features.
Contributions:
- fixes and refactoring of the computation of radial shells and layers for the refined, radially equidistant IcosahedralShellMesh
- a new class `RadialShellData` to gather and store the FE data in radial layers without connectivity
- VTK output for point clouds (general point clouds, not limited to the radially organized data above) via `VTKPointCloudOutput`
- a helper function to interpolate the radial shell ID to FE functions (can be used to filter radial shells in post-processing)
- a helper function to interpolate the number of duplicated nodes in the VTK/ADIOS output (currently all data including ghost-nodes is written for each macro-volume - this creates duplicates - they can be detected/filtered with this additional data)
# Note on layers vs shells
There are some issues regarding the nomenclature of *shell* and *layer*. It appears that their definition is unclear. We need to distinguish between
- (what I currently call *shell*) 2D manifolds in 3D space, i.e., the boundaries of a sphere (centered at the origin) with a specific radius, and
- (what I currently call *layer*) 3D volumes that have two such manifolds as boundaries.
Unfortunately, these definitions are not used consistently, especially in older code and documentation (see e.g. documentation of the MeshInfo).
# Plots of the point cloud output
Example 1: all shells selected:
![point_cloud_vtk_01](/uploads/defc4e40d2eaf083c26d2478ec2cfd74/point_cloud_vtk_01.png)
Example 2: only two selected shells:
![point_cloud_vtk_02](/uploads/0d6dd3ac87d1aeee10eb25e740050fc0/point_cloud_vtk_02.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/753Draft: Radial shell output2024-06-07T17:32:23+02:00Nils KohlDraft: Radial shell outputThis MR implements output of FE coefficients (P1 and P2, scalar and vector-valued) to point clouds that are organized in radial shells for the thick spherical shell mesh (with blending).
The scope is as follows:
- [x] a new class `Radia...This MR implements output of FE coefficients (P1 and P2, scalar and vector-valued) to point clouds that are organized in radial shells for the thick spherical shell mesh (with blending).
The scope is as follows:
- [x] a new class `RadialShellData` to gather and store the FE data in radial layers
- [x] VTK output for point clouds (general point clouds - including those generated above) via `VTKPointCloudOutput`
- [ ] test P2 since edge DoFs and shells must somehow be organized meaningfully
- [ ] ~~ADIOS2 output (requires ADIOS2 consulting from @mohr)~~
It hopefully will also resolve issues regarding the nomenclature of *shell* and *layer* as well as corresponding computations. It appears that their definition is unclear. We need to distinguish between
- (what I currently call *shell*) 2D manifolds in 3D space, i.e., the boundaries of a sphere (centered at the origin) with a specific radius, and
- (what I currently call *layer*) 3D volumes that have two such manifolds as boundaries.
Unfortunately, these definitions are not used consistently, even in older code and documentation.
-----
VTK seems to work already for P1:
Example 1: all shells selected:
![point_cloud_vtk_01](/uploads/defc4e40d2eaf083c26d2478ec2cfd74/point_cloud_vtk_01.png)
Example 2: only two selected shells:
![point_cloud_vtk_02](/uploads/0d6dd3ac87d1aeee10eb25e740050fc0/point_cloud_vtk_02.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/707Draft: Adding tool for temperature initialisation2024-03-27T15:05:44+01:00Eugenio D'AscoliDraft: Adding tool for temperature initialisationFor the temperature initialisation a new tool "InitialisationTool.hpp" is now
available within the src/terraneo/helpers directory. Temperature initialisation is
performed superimposing a distinct amount of white noise or temperature devi...For the temperature initialisation a new tool "InitialisationTool.hpp" is now
available within the src/terraneo/helpers directory. Temperature initialisation is
performed superimposing a distinct amount of white noise or temperature deviations from spherical harmonics onto the reference
temperature profile (currently adiabatic profile). This should allow us to modularise initialisation procedures in convection apps and
lets us stay closer to master according to issue #243 .Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/718Integrating Stokes solvers from branch burk/ELWMS.2024-03-20T12:01:56+01:00Nils KohlIntegrating Stokes solvers from branch burk/ELWMS.Mostly taking files that have been introduced by Andi Burkhart on the burk/ELWMS branch (specifically at 0a3cdd49a6a15782b46d5acfae8305ce88a1a4cf).
This MR introduces new and more modular Stokes preconditioners and adds necessary featur...Mostly taking files that have been introduced by Andi Burkhart on the burk/ELWMS branch (specifically at 0a3cdd49a6a15782b46d5acfae8305ce88a1a4cf).
This MR introduces new and more modular Stokes preconditioners and adds necessary features to use them with the new generated operators.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/649Draft: To GeometryMap add a method to compute second derivatives2024-02-29T09:46:16+01:00Marcus MohrDraft: To GeometryMap add a method to compute second derivativesMain purpose of this MR is to add to our geometry maps the functionality to compute second derivaties as is e.g. needed for SUPG stabilisiation.Main purpose of this MR is to add to our geometry maps the functionality to compute second derivaties as is e.g. needed for SUPG stabilisiation.Andreas BurkhartAndreas Burkharthttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/632Draft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise DoFValueOperators (+Tests), Second derivatives for the Blending Maps, PETScHDF5 ...2024-02-21T17:05:49+01:00Andreas BurkhartDraft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise DoFValueOperators (+Tests), Second derivatives for the Blending Maps, PETScHDF5 Function Saving, Projection subclasses for Smoothers and Restriction/Prolongation**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content o...**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content of the various diffs:
**composites/P2P1TaylorHoodCompStokesOperator.hpp:** Implements a P2P1 Block Operator for the compressible Stokes (both ALA and TALA are available) with potentially temperature dependent viscosity. It can also generate an appropriate right hand side. You can also activate or deactivate the frozen velocity approach (i.e. if the compressible term in the mass conservation equation is made explicit).
LHS velocity:
$$2 \int_{\Omega} \eta(x,T) \sigma(u) : \sigma(v) \text{ } dx - \frac{2}{\text{dim}} \int_{\Omega}{\eta(x,T) (\nabla \cdot u) \cdot (\nabla \cdot v)} \text{ } dx - \int_{\Omega} \text{div}(v)p_d \text{ } dx - \int_\Omega \frac{\text{Di}}{\Gamma_0} \rho(x) (K_T)^{-1} p_d g \cdot v \text{ } dx$$
RHS velocity:
$$-\int_\Omega \frac{\text{Ra}}{\text{Pe}} \rho(x) \alpha T_d g \cdot v \text{ } dx$$
LHS pressure (here without frozen velocity):
$$ -\int_\Omega \left (\frac{\nabla \rho(x)}{\rho(x)} \cdot u \right ) q \text{ } dx - \int_\Omega (\nabla \cdot u) q \text{ } dx$$
RHS pressure: 0
**src/p2functionspace/P2CompTransportOperator.hpp:** Implements a P2 Operator for the time (in-)dependent energy conservation equation with optional SUPG Stabilisation. Various time stepping schemes (implicit Euler, BDF2, Crank-Nicolson) are available (some additional function calls from outside might be required, e.g. the operator provides a method to save the previous time step right hand side for crank nicolson). Can also be used for the diffusion solve step when using the MMOC operator splitting approach. It can also generate an appropriate right hand side.
LHS temperature (here for the adiabatic heat on the lhs, but can be also be made explicit):
$$ \int_\Omega \frac{\partial T}{\partial t} w \text{ } dx + \int_\Omega (u \cdot \nabla T) w \text{ } dx + \int_\Omega \frac{k }{\text{Pe} \text{ } C_p}\nabla T \cdot \nabla \left ( \frac{w}{\rho(x)} \right ) \text{ } dx - \int_\Omega \text{Di} \text{ } \frac{\alpha}{C_p} T (u \cdot g )w \text{ } dx + \text{SUPG Terms (if used)}$$
RHS temperature:
$$ - \int_\Omega \frac{1}{C_p} H w \text{ } dx -\int_\Omega \frac{\text{Pe}}{\rho(x) C_p}\frac{\text{Di}}{\text{Ra}} \left (\tau\left (u,\eta\left (x,T \right )\right ) : {\varepsilon(u)}\right ) w \text{ } dx + \text{SUPG Terms (if used)}$$
The lhs and rhs above are consequently also dependent on the chosen time discretisation.
**src/hyteg/p2functionspace/P2FullViscousTDependentOperator.hpp, src/hyteg/p2functionspace/P2GradRhoRho_P2_Operator.hpp, src/hyteg/p2functionspace/P2ScaledMassDiffusionOperator.hpp, src/hyteg/p2functionspace/P2VariableBlendingKMassScalarToVectorOperator.hpp, src/hyteg/gridtransferoperators/P2toP1GradRhoRho_P2_Operator.hpp, src/hyteg/gridtransferoperators/P1toP2VariableBlendingKMassScalarToVectorOperator.hpp:** Various operators that conveniently combine the usage of multiple other operators (e.g. if we apply one on every component).
**src/elementwiseoperators:** Added all combinations of P1/P2 ElementwiseDoFValueOperator classes. These operators can be inherited from and provide a way (via the DoFValues_ vector) to access the DoFs of another FEM function during the evaluation of a form. This allows us for the creation of operators like an advection operator that takes a velocity field as an additional input.
Added a setConstantScaling function to all elementwise operators. This can be used to scale your operators by a constant on the fly (without having to create for example a linear combination form).
There are some bug fixes and the ability to use a custom form for P2ToP1 and P1ToP2 elementwise operators included.
**src/elementwiseoperators/generated:** Folder containing all of the generated ElementwiseDoFValueOperators. In particular it adds operators for adiabatic heating, advection, diffusion (only supg), temperature dep. stokes, the grad(rho)/rho * u compressible term in the mass conservation equation, div_k_grad scaled by rho^-1, mass(only supg), shear heat and respective SUPG Stabilisation terms.
**src/p1functionspace/VertexDoFFunction, src/edgedofspace/EdgeDoFFunction, src/functions/DoFValueFunctions:** Added a DoFValueFunction class that both VertexDoFFunction and EdgeDoFFunction inherit from. No previous functionality of VertexDoFFunction and EdgeDoFFunction was changed, I just implemented the additional functions defined in the DoFValueFunction base class. The defined functions are required for the DoFValueOperators to work.
**src/hyteg/composites/VelocityOperator_T_Wrapper, src/hyteg/solvers/SubstituteSolver.hpp:** Some convenient wrappers, allowing you to wrap a operator with a different VelocityOperator_T type and to use a solver for a different operator type (e.g. if you want to solve Laplace as a preconditioner, but the preconditioner is expected to be a solver for a different operator).
**src/petsc/PETScHDF5FunctionSave.hpp:** Functions that allow you to save functions and paramters via creating a PETSc Vector and saving it in parallel to a binary file via HDF5. Has some limitations since you can only reload your functions in the same configuration as you saved it.
**src/solvers/preconditioners/stokes:** Two preconditioner classes used for benchmarks and the convection model
**src/solvers/solvertemplates/StokesSolverTemplates.hpp:** Pulled over some changes to the StokesSolverTemplates solver used in the other Terraneo branches. No functionality is changed but you can now distinguish between absolute and relative tolerance.
**src/solvers/ChebyshevSmoother.hpp:** Added a subclass of the Chebyshev Smoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/solvers/GMRESSolver.hpp:** Serveral bug fixes and additional functions from Andreas Wagner to the GMRES solver which we found during our testing of the GMRES.
**src/solvers/MinResSolver.hpp:** Pulled over some changes to the MinRes solver used in the other Terraneo branches. No functionality is changed but you can now define an absolute tolerance.
**src/solvers/UzawaSmoother.hpp, /src/hyteg/composites/P2P1UzawaDampingFactorEstimationOperator.hpp:** Added functions for the estimation of the Uzawa Omega paramter also in case of the P2CompStokesOperator and added a subclass of the UzawaSmoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesProlongation.hpp, src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesRestriction.hpp:** Restriction and Prolongation operator subclasses that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**data/meshes:** Just some additional meshes which are offset from the origin (are used for testing with the sphericalCoordinateMap blending map.
**src/forms:** Just some additional generated blending forms.
**src/geometry:** Added second derivative functions (needed for SUPG Stabilisiation) for all blending maps and a new spherical coordinate map.
**tests/hyteg/operators:** Added tests checking if the various DoFValueOperators are calculating the correct integrals and if the diagonal calculation for the temperature dependent stokes works.
Hopefully I haven't forgotten anything and these are all changes.Andreas BurkhartAndreas Burkharthttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/634Allow to remove functions from an FEFunctionRegistry or FunctionMultiStore object2023-07-27T17:22:53+02:00Marcus MohrAllow to remove functions from an FEFunctionRegistry or FunctionMultiStore objectThe implementation of this feature touches on issues #172 and #186.The implementation of this feature touches on issues #172 and #186.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/510Draft: Plate velocity computations2022-06-23T16:39:52+02:00Dominik Thoennesdominik.thoennes@fau.deDraft: Plate velocity computationsAdds a first draft for computing plate velocities for mantle convection simulations from reconstructed plate motions. The draft
is originally based on
[https://gitlab.lrz.de/marcus.mohr/plates-refactoring/-/tags/HYTEG_INCLUSION_CANDIDA...Adds a first draft for computing plate velocities for mantle convection simulations from reconstructed plate motions. The draft
is originally based on
[https://gitlab.lrz.de/marcus.mohr/plates-refactoring/-/tags/HYTEG_INCLUSION_CANDIDATE_1](https://gitlab.lrz.de/marcus.mohr/plates-refactoring/-/tags/HYTEG_INCLUSION_CANDIDATE_1)Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/493DG pt. 12022-04-04T10:50:46+02:00Nils KohlDG pt. 1See #171.
This MR introduces the basic data structures for the 2D DG implementation.See #171.
This MR introduces the basic data structures for the 2D DG implementation.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/342Draft: Resolve "Implement forms needed for P2-P1 Stokes with blending"2020-07-29T16:48:23+02:00Marcus MohrDraft: Resolve "Implement forms needed for P2-P1 Stokes with blending"Closes #126Closes #126