hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2024-08-30T11:47:17+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/821[Rebased] MicroMesh & iso-/super-/sub-parametric elements2024-08-30T11:47:17+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/822Allow exporting a refined mesh from HyTeG2024-08-29T12:40:09+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/601Draft: Access to individual DoFs2024-06-06T08:50:47+02:00Marcus MohrDraft: Access to individual DoFs# Idea
The idea of this suggested extension is to allow read/write access to individual degrees of freedom of a FE-function from the outside. IMHO this could provide an easy and practical way for users to implement functionality that is ...# Idea
The idea of this suggested extension is to allow read/write access to individual degrees of freedom of a FE-function from the outside. IMHO this could provide an easy and practical way for users to implement functionality that is currently not (directly) representable by the available function class methods. We see that in these cases either existing methods, such as e.g. `interpolate()`, are creatively (mis)used to accomplish the respective goal, or needlessly expensive workarounds, such as e.g. `velocityMaxMagnitude()` from `CFDHelpers.cpp` need to be implemented.
# DoFAccessors
In the current proof-of-concept implementation access to a degree of freedom is accomplished via two templated free-functions
- `readDoFValue()`
- `writeDoFValue()`
The rationale for not *just* providing a function such as e.g. `accessDoF()`, which returns a reference to the data item, is to be able to implement the two functions also for our `CSFVectorFunction`s, as in that case no underlying dof-vector exists, which could be referenced.
# DoFIdentifiers
A DoF is identified by a corresponding *DoFIdentifier* object. In the case of a `P1DoFIdentifier` this, e.g., is a class storing the following
three pieces of information: level to work on, ID of associated primitive and the integer index into the data array for the function.
```c++
class P1DoFIdentifier : public BaseDoFIdentifier
{
public:
P1DoFIdentifier(){};
~P1DoFIdentifier(){};
PrimitiveID primitiveID_;
uint_t level_;
uint_t arrayIndex_;
bool operator==( const P1DoFIdentifier& other ) const
{
return ( primitiveID_ == other.primitiveID_ ) && ( arrayIndex_ == other.arrayIndex_ ) && ( level_ == other.level_ );
}
};
```
# DoFIterators
In order for the user to allow to work with the accessors, the idea is to have **iterators** which can be used to "loop" over all degrees of freedom of a specific function class. Note that this is local, i.e. the iterator only treats dofs/primitives owned by the corresponding MPI process. Currently the draft implements to iterators:
- `P1DoFIterator`
- `EdgeDoFIterator`
In order to demonstrate the validity and usefulness of the concept there are two tests:
- `DoFIterator+AccessTest.cpp`: demonstrates the basic use of the concept and checks that we can iterate over all DoFs (externally)
- `CSFVectorFunctionMagnitudeTest.cpp`: Implements the `getMaxMagnitude()` functionality that is currently missing from the `CSFVectorFunction` class using the dof accessor idea.
# Remarks
- Note that this is only a demo implementation. Hence there is much room for improvement. Especially the iterators should be improved, if we want to go with this approach.
- Another questions is, whether an iterator should also provide a flag to only include certain primitives, in the same way as e.g. the `interpolate()` and `apply(()` methods.
- For full usability one would often also need to obtain the micro-coordinates for a DoF (if avalaible for the corresponding FE function representation). This could be handled in multiple ways
- as part of a specialised iterator that adds this info to the dof identifier
- by a separate query method
- as a secondary `readDoFValue()` function that also returns the coordinates
Please feel free to comment.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/738Draft: Dechant/laplace beltrami2024-05-07T21:25:11+02:00Maximilian DechantDraft: Dechant/laplace beltramiImplements P1- and P2-forms for the Laplace-Beltrami-Operator on 2D-manifolds in 3D-space.
Implements Laplace-Beltrami-App to test Laplace-Beltrami-Operator in combination with blending, surrogates and multigrid.Implements P1- and P2-forms for the Laplace-Beltrami-Operator on 2D-manifolds in 3D-space.
Implements Laplace-Beltrami-App to test Laplace-Beltrami-Operator in combination with blending, surrogates and multigrid.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/703Draft: Scalable operators and other prerequisites for further merge requests2024-04-08T13:42:11+02:00Andreas BurkhartDraft: Scalable operators and other prerequisites for further merge requestsContents:
- made constant and elementwise operators scalable by a constant
- added fenics form compatability functions to some form headers (required for constant operator scaling)
- added some new forms
- elementwise operators can now a...Contents:
- made constant and elementwise operators scalable by a constant
- added fenics form compatability functions to some form headers (required for constant operator scaling)
- added some new forms
- elementwise operators can now also return lumped diagonal values and lumped inverse diagonal values
- some minor changes to P2ToP1 and P1ToP2 Elementwise Operators to allow for the usage of variable forms
- added DoFValueFunction interface to VertexDofFunction and EdgeDofFunction as a prerequisite for DoFValueOperators
- made the geometryMap in Form.hpp mutable (this is required for DoFValueOperators, due to issues with const correctness, I know this looks wrong)
First of all: I'm sorry. In my opinion this is the smallest package that makes sense for this.
Some notes:
- Nils and I have already spoken about applying operators in a scaled fashion of the form A.apply(s, d, $\alpha$. $\beta$) effectively evaluating to $\alpha \cdot d + \beta \cdot A s$. For now however I need a solution like this to make creating new operators and especially time stepping schemes tolerable. Another solution would be to have a very general class for an operator linear combination (preferably that is not inefficient and uses lots of temporary functions!).
- I plan to at least offer the old DoFValueOperators as a comparison tool and for some legacy tests in a future merge request. They will go into their own submodule perhaps, where they don't annoy other users.Andreas BurkhartAndreas Burkhart