hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2023-10-19T12:20:24+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/653Particles2023-10-19T12:20:24+02:00Nils KohlParticlesThis MR implements unresolved particles via the MESA-PD particle code generation framework.
The objective is the implementation of **fluid (<)-> particle** and later **particle <-> particle** interactions. Since the particles are assume...This MR implements unresolved particles via the MESA-PD particle code generation framework.
The objective is the implementation of **fluid (<)-> particle** and later **particle <-> particle** interactions. Since the particles are assumed to be smaller than the elements, the module is referred to as _unresolved particles_. Thus fluid-particle interactions are not meant to be fully resolved but are modeled instead. At this point, only the one-way coupling (fluid acts on particles, not vice versa) is considered.
This is sufficient to, e.g., implement tracer particles.
Some notes:
* The implementation is already fully parallelized.
* There is a new tutorial (no. 12) including some images.
* The particle properties are subject to change and probably need to be discussed in the future. As of now, it is possible to flexibly add custom real and integer scalars to particles if needed.
* Direct application of velocity and force fields is possible. For tracer particles, the former is sufficient and can be interpreted as a extremely simplified form of Faxén's law (https://en.wikipedia.org/wiki/Fax%C3%A9n%27s_law). Force fields are also already supported, and naturally involve the particle mass for the computation of the resulting translational velocity.
* Theoretically, all features that are available in MESA-PD can be used. This includes, for instance, other integrators. However, using them involves generating the corresponding C++ code via MESA-PD through the python script in the `data/codegen/unresolved_particles/` directory.
* I had in mind that there has been a temporary(?) tracer particle implementation in the TerraNeo module. I cannot find it right now (could be on a branch) - and I might be wrong. If there is one, we should consider replacing it (and add required features to this new version - if possible).
* Blended domains are not yet supported.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/642First version of parallel PrimitiveStorage setup from file.2023-10-23T13:54:07+02:00Nils KohlFirst version of parallel PrimitiveStorage setup from file.This MR realizes a two-step process. First, in a serial (offline) run, the SetupPrimitiveStorage is built and passed to a load balancer, followed by serialization to a file. During the actual, parallel run, the file is read via MPIIO suc...This MR realizes a two-step process. First, in a serial (offline) run, the SetupPrimitiveStorage is built and passed to a load balancer, followed by serialization to a file. During the actual, parallel run, the file is read via MPIIO such that only the portion that is necessary has to be viewed by the respective process. From that binary string, the entire PrimitiveStorage is created in parallel.
There are numerous possible optimizations - most notably, it is not clear to me right now if the current approach of simply writing all neighbor primitives to file is preferable, or if alternatively, such data should be communicated after only reading the locally allocated primitives. Maybe it does not even make a difference at all. Also, this implementation has not been tested with large setups yet.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/635Enhance functionality of FEFunctionRegistry and FunctionMultiStore2023-07-28T14:21:17+02:00Marcus MohrEnhance functionality of FEFunctionRegistry and FunctionMultiStoreThe `FEFunctionRegistry` and `FunctionMultiStore` classes are extended to
- allow to remove functions again; note: this technically touches on issues #172 and #186
- only store functions once, where uniqueness is based on the function's...The `FEFunctionRegistry` and `FunctionMultiStore` classes are extended to
- allow to remove functions again; note: this technically touches on issues #172 and #186
- only store functions once, where uniqueness is based on the function's name
This MR supersedes !634.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/600Allow asking a Primitive for its type2023-05-19T17:19:54+02:00Marcus MohrAllow asking a Primitive for its typeIn most of our current algorithms we (implicitely) know what type of primitive we are dealing with, i.e. whether we are working on a `Cell`, `Face`, `Edge` or `Vertex`. This largely results from the fact that we ask a `PrimitiveStorage` ...In most of our current algorithms we (implicitely) know what type of primitive we are dealing with, i.e. whether we are working on a `Cell`, `Face`, `Edge` or `Vertex`. This largely results from the fact that we ask a `PrimitiveStorage` object to provide us with all local primitives of a certain type, e.g. via `PrimitiveStorage::getFaces()`.
Still to me it feels strange that we can neither query an object of type `Primitive` to obtain its type, nor that this is encoded in its associated `PrimitiveID`. There are some situations, where we might not (implicitely) know what kind of primitive we are dealing with. An example at the moment would be the migration of primitives between MPI processes. As a consequence of this the `PrimitiveStorage` class defines its own `PrimitiveTypeEnum` and provides a `getPrimitiveType()` method, which, presented with a `PrimitiveID` will return the type of the primitive, if this is either present locally, or in the immediate neighbourhood. If not, it will return `INVALID`.
The idea of this MR is to equip the `Primitive` class itself with a `PrimitiveTypeEnum` type that only has the values `CELL`, `FACE`, `EDGE` and `VERTEX` and a pure virtual function `Primitive::getType()` that can be used to query this. The latter is then easily implemented in the child classes.
The MR preserves `PrimitiveStorage::PrimitiveTypeEnum`, because I did not want to add a special situation `INVALID` enum to `Primitive::PrimitiveTypeEnum`. The former quasi extends the latter, based on fixed int values, so that we can cast the former into the latter.
That feels not ideal, but I am too unfamiliar with the details of primitive migration to understand, why we might want to send a nullptr together with an `INVALID` from one process to another, to change that.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/597Add function for writing blended coarse mesh2023-05-12T10:04:52+02:00Daniel BauerAdd function for writing blended coarse meshWith this MR we can visualize meshes on the physical domain.
![image](/uploads/2412529a9f21b3c4d7b2c3d6cacd1f7a/image.png)
Edit: Now, VTP and poly lines are used.With this MR we can visualize meshes on the physical domain.
![image](/uploads/2412529a9f21b3c4d7b2c3d6cacd1f7a/image.png)
Edit: Now, VTP and poly lines are used.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/594Allow use of isoparametric elements in VTKOutput for P2Functions2023-06-22T17:38:46+02:00Marcus MohrAllow use of isoparametric elements in VTKOutput for P2FunctionsThe merge introduces a change to the functionality of the `VTKOutput` class. When writing `P2(Vector)Function`s the default now is to use *VTK_QUADRATIC_TRIANGLE* or *VTK_QUADRATIC_TETRA* as cell type.
The old way to export these functi...The merge introduces a change to the functionality of the `VTKOutput` class. When writing `P2(Vector)Function`s the default now is to use *VTK_QUADRATIC_TRIANGLE* or *VTK_QUADRATIC_TETRA* as cell type.
The old way to export these functions as `P1Function`s on a refined mesh is for the moment still supported and can be activated by calling
- `setUseVTKQuadraticTriangle( false )` or
- `setUseVTKQuadraticTetra( false )`
on the corresponding `VTKOutput` object.
Comparison of the old versus the new approach looks good so far. In the following figures the left part shows a visualisation with the old and the right with the new approach:
![VTK_Quadratic_Triangle-partialAnnulus](/uploads/7fc7c7ed185be1f2fd4bd6ab77057d21/VTK_Quadratic_Triangle-partialAnnulus.png)
![VTK_QUADRATIC_TETRA_3TETS_LVL2-v2](/uploads/3a5ce647b6dca79acc120c590bca1df5/VTK_QUADRATIC_TETRA_3TETS_LVL2-v2.png)Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/585Add isIdentity and isAffine to GeometryMap2023-04-20T17:38:29+02:00Daniel BauerAdd isIdentity and isAffine to GeometryMapFixes hyteg/hyteg#208.Fixes hyteg/hyteg#208.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/584Enriched Galerkin functionspace2023-04-19T19:31:44+02:00Fabian BöhmEnriched Galerkin functionspaceAdds the Enriched Galerkin discretization to HyTeG, contained in directory src/hyteg/egfunctionspace:
- Forms for mass, div, divt, Laplacian and epsilon
- corresponding operators with and without Nitsche-type boundary conditions (Nits...Adds the Enriched Galerkin discretization to HyTeG, contained in directory src/hyteg/egfunctionspace:
- Forms for mass, div, divt, Laplacian and epsilon
- corresponding operators with and without Nitsche-type boundary conditions (Nitsche-operators are preferred due to their symmetry)
- a Stokes-function and operators in directory src/hyteg/composites
- interpolation operators between DG and CG of first degree with P1toDGOperator in directory src/hyteg/dgfunctionspace
- additional addVolumeGhostlayer functionality in vertexDoFFunction required in P1toP0Operator and P0toP1Operator
Two benchmarks with strongy varying viscosity from literature reside in apps/2022-eg-varvisc.
tests/hyteg/egfunctionspace contains tests for operator symmetry, forms, matvec/apply, basic operations of EGFunction and convergence tests.https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/574add MPI Version to buildInfo2023-03-20T18:11:39+01:00Dominik Thoennesdominik.thoennes@fau.deadd MPI Version to buildInfohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/565VolumeDoF Packinfo 2D (pack + unpack)2023-02-10T20:19:46+01:00Nils KohlVolumeDoF Packinfo 2D (pack + unpack)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/553Disentangle VectorFunction dimension from hasGlobalCells()2022-12-16T18:11:35+01:00Marcus MohrDisentangle VectorFunction dimension from hasGlobalCells()After the merge we can construct P[12]VectorFunction objects that represent 3D fields living on 2D surfaces and export them to vtu-files.After the merge we can construct P[12]VectorFunction objects that represent 3D fields living on 2D surfaces and export them to vtu-files.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/552Add a SphericalElementFormMass2022-12-16T14:06:38+01:00Marcus MohrAdd a SphericalElementFormMassThis merge demonstrates that we can successfully apply an ElementwiseOperator to a scalar function on a 2D surface in 3D.This merge demonstrates that we can successfully apply an ElementwiseOperator to a scalar function on a 2D surface in 3D.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/549Add Nedelec edge elements of type I and order 12022-12-16T17:55:09+01:00Daniel BauerAdd Nedelec edge elements of type I and order 1Nedelec elements [1] are implemented in class `N1E1VectorFunction`.
They are useful for problems in H(curl).
The notation follows the Periodic Table of the Finite Elements [2].
Additionally, the hybrid smoother by Hiptmair [3] is impleme...Nedelec elements [1] are implemented in class `N1E1VectorFunction`.
They are useful for problems in H(curl).
The notation follows the Periodic Table of the Finite Elements [2].
Additionally, the hybrid smoother by Hiptmair [3] is implemented.
[1] J. C. Nedelec, “Mixed finite elements in ℝ3,” Numer. Math., vol. 35, no. 3, pp. 315–341, Sep. 1980, doi: [10.1007/BF01396415](https://doi.org/10.1007/BF01396415).<br>
[2] D. N. Arnold and A. Logg, “Periodic Table of the Finite Elements,” SIAM News, Nov. 2014. Accessed: Jul. 04, 2022. [Online]. Available: https://www-users.cse.umn.edu/~arnold/femtable<br>
[3] R. Hiptmair, “Multigrid Method for Maxwell’s Equations,” SIAM J. Numer. Anal., vol. 36, no. 1, pp. 204–225, Jan. 1998, doi: [10.1137/S0036142997326203](https://doi.org/10.1137/S0036142997326203).Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/544Demonstrators for working with Surfaces in 3D2022-11-29T16:33:06+01:00Marcus MohrDemonstrators for working with Surfaces in 3DMotivated by the issue that led to [6b4c8e95] I tested the possibility to work with **3D surfaces** in HyTeG. As it turns out this works at least partially. We can construct them, use them to generate function objects, interpolate expres...Motivated by the issue that led to [6b4c8e95] I tested the possibility to work with **3D surfaces** in HyTeG. As it turns out this works at least partially. We can construct them, use them to generate function objects, interpolate expressions into the associated FE spaces and output the functions for visualisation correctly.
I added a tiny `3DSurfaceDemo` app to show that and adapted the `SPHdemo` to allow computing the spherical harmonics only on a thin shell:
![SphericalHarmonic-deg5-order3](/uploads/63b5bf62f189c0db14ccfe0786326ebc/SphericalHarmonic-deg5-order3.png)
What I did not test so far is anything operator related, though.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/535Resolve issue #1842022-12-06T16:25:39+01:00Marcus MohrResolve issue #184The merge will make the evaluate() and evaluateGradient() methods of P[12]Function and DGFunction expect physical instead of computational coordinates. Additionally it fixes the problem with piecewise defined blending maps described as p...The merge will make the evaluate() and evaluateGradient() methods of P[12]Function and DGFunction expect physical instead of computational coordinates. Additionally it fixes the problem with piecewise defined blending maps described as part of issue #184.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/531Micro-cell refinement: function to compute fine-level micro-cell indices.2022-10-31T20:19:23+01:00Nils KohlMicro-cell refinement: function to compute fine-level micro-cell indices.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/529Implement AffineMap[23]D::evalFinv() amd fix/extend AffineMap3DTest2022-10-25T21:55:36+02:00Marcus MohrImplement AffineMap[23]D::evalFinv() amd fix/extend AffineMap3DTestMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/524Adaptive mesh refinement for DG2022-08-31T11:28:46+02:00Nils KohlAdaptive mesh refinement for DGThis merge request adds the functionality to perform adaptive mesh refinement (AMR) in 2D for the discontinuous Galerkin method with hanging nodes.
At this point we are not feature complete, but the most important basic functionality is...This merge request adds the functionality to perform adaptive mesh refinement (AMR) in 2D for the discontinuous Galerkin method with hanging nodes.
At this point we are not feature complete, but the most important basic functionality is implemented. Especially 3D and parallel support is (yet) missing. The implementation is designed with these extensions in mind.
Most important changes:
**PrimitiveID tree structure**
Extended the internal representation to model tree-like relationships between IDs. Children of IDs can be created, ensuring that no duplicate IDs are created even in parallel settings. This is vital to parallel/distributed AMR. Similar to what is done in walberla's BlockID class but tailored to the requirements in HyTeG.
**PrimitiveStorage refinement**
Macro-primitives can now be refined, creating a hierarchy with potentially hanging nodes. The storage is now organized in a tree-like structure. Methods have been implemented that allow refinement while maintaining a 2:1 balance among neighboring volume macros.
**VolumeDoFFunction**
The VolumeDoFFunction has been extended to support the ghost-layer allocation and communication mechanisms required for DG AMR. Also various new indexing functions allow for translation of indices between macro- and micro-refinement levels.
**DG**
The DGOperator was augmented to take care of correct element integration and ghost-layer accesses so that AMR is now seamlessly integrated into the matrix-vector multiplication and sparse assembly.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/518Adds computation of velocity boundary conditions from information on tectonic plates2022-07-05T19:27:52+02:00Marcus MohrAdds computation of velocity boundary conditions from information on tectonic platesThe merge adds functionality for compute plate velocities to the TerraNeo module. These plate velocities can be used to set velocity boundary conditions for the Stokes part of a mantle convection model.The merge adds functionality for compute plate velocities to the TerraNeo module. These plate velocities can be used to set velocity boundary conditions for the Stokes part of a mantle convection model.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/505GKB merge2022-08-30T14:11:44+02:00Fabian BöhmGKB mergeAdds access/implementation of two versions of the Golub-Kahan Bidiagonalization (GKB) solver to HyTeG:
- the GKB implementation from PETSc can be run via PETScBlockPreconditionedStokesSolver
- an own implementation of GKB on HyTeGs dat...Adds access/implementation of two versions of the Golub-Kahan Bidiagonalization (GKB) solver to HyTeG:
- the GKB implementation from PETSc can be run via PETScBlockPreconditionedStokesSolver
- an own implementation of GKB on HyTeGs datastructures in GKBSolver.hpp
Adds an augmented Lagrangian operator used by the HyTeG implementation of GKB
Adds python scripts for the work unit calculation of solver configurations