hyteg merge requests
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests
2024-03-20T15:56:34+01:00
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/727
[Rebased] Integrating Stokes solvers from branch burk/ELWMS.
2024-03-20T15:56:34+01:00
Nils Kohl
[Rebased] Integrating Stokes solvers from branch burk/ELWMS.
Rebased - see !718.
Rebased - see !718.
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/723
Generated Stokes operators with annulus blending
2024-03-15T14:49:45+01:00
Nils Kohl
Generated Stokes operators with annulus blending
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/718
Integrating Stokes solvers from branch burk/ELWMS.
2024-03-20T12:01:56+01:00
Nils Kohl
Integrating 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 Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/716
GEMV
2024-03-21T21:55:14+01:00
Nils Kohl
GEMV
This MR implements the `gemv` as described in detail in #253.
It turns out that only minor changes have to applied to the `apply()` method to make this work (at least for the elementwise operators).
This MR implements the `gemv` as described in detail in #253.
It turns out that only minor changes have to applied to the `apply()` method to make this work (at least for the elementwise operators).
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/713
Extend geometry getter functions of Face and Cell class
2024-02-29T15:25:13+01:00
Marcus Mohr
Extend geometry getter functions of Face and Cell class
This MR adds three new functions:
- `Face::getIncircleRadius()`
- `Cell::getVolume()`
- `Cell::getInsphereRadius()`
We test these together with the existing `Face::getArea()` function in the new **Face+CellGeometryTest**.
This MR adds three new functions:
- `Face::getIncircleRadius()`
- `Cell::getVolume()`
- `Cell::getInsphereRadius()`
We test these together with the existing `Face::getArea()` function in the new **Face+CellGeometryTest**.
Marcus Mohr
Marcus Mohr
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/710
New generated Stokes operators
2024-03-06T08:34:39+01:00
Nils Kohl
New generated Stokes operators
See #246 for extended discussion
----
## Checklist:
- [x] `hyteg-operators` submodule needs to be updated as soon as https://i10git.cs.fau.de/hyteg/hyteg-operators/-/merge_requests/3 is merged
- [x] fix unused variable warnings in gen...
See #246 for extended discussion
----
## Checklist:
- [x] `hyteg-operators` submodule needs to be updated as soon as https://i10git.cs.fau.de/hyteg/hyteg-operators/-/merge_requests/3 is merged
- [x] fix unused variable warnings in generated operators
- [x] [move divergence, gradient, viscous directories out of the stokes directory and under `hyteg_operators_composites` instead](https://i10git.cs.fau.de/hyteg/hyteg/-/issues/246#note_28717)
- [x] fix issues for `real_t = float` (single precision builds)
- [x] blending operators test
----
## New module `hyteg_operators_composites`
This MR adds a new module `hyteg_operators_composites` that contains composite operators that are built from generated operators.
For now, three variants of Stokes operators have been added:
* P2P1StokesConstantOperator
* P2P1StokesEpsilonOperator
* P2P1StokesFullOperator
including the necessary viscous, divergence and gradient operators plus their `IcosahedralShellMap` blending versions.
The new module also comes with a short README.
## Testing
The MR extends and modifies
* P2P1ElementwiseStokesOperatorTest (Stokes constant, 2D + 3D)
* P2P1ElementwiseStokesOperatorTest (full Stokes w/ blending, 3D)
* ElementwiseEpsilonMinResConvergenceTest (Stokes epsilon, 2D + 3D)
* DivergenceOperatorTest (divergence, 2D + 3D)
* ViscousOperatorsTest (epsilon + full viscous block, 2D )
to test the new composites.
At least the 2D versions of all non-blending Stokes operators are now tested to some extent.
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/707
Draft: Adding tool for temperature initialisation
2024-03-27T15:05:44+01:00
Eugenio D'Ascoli
Draft: Adding tool for temperature initialisation
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 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 Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/706
First version of an abstract reduce function
2024-06-13T12:51:42+02:00
Dominik Thoennes
dominik.thoennes@fau.de
First version of an abstract reduce function
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 ...
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/705
Add Stokes benchmarks for annulus and thick spherical shell settings
2024-02-22T13:47:51+01:00
Marcus Mohr
Add Stokes benchmarks for annulus and thick spherical shell settings
The benchmarks are based on and extend, w.r.t. boundary conditions, those described in [Analytical solutions for mantle flow in cylindrical and spherical shells](https://doi.org/10.5194/gmd-14-1899-2021) by Kramer et al.
Also noteworthy...
The benchmarks are based on and extend, w.r.t. boundary conditions, those described in [Analytical solutions for mantle flow in cylindrical and spherical shells](https://doi.org/10.5194/gmd-14-1899-2021) by Kramer et al.
Also noteworthy is the addition of a `PythonCallingWrapper` class.
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/703
Draft: Scalable operators and other prerequisites for further merge requests
2024-04-08T13:42:11+02:00
Andreas Burkhart
Draft: Scalable operators and other prerequisites for further merge requests
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 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 Burkhart
Andreas Burkhart
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/676
Add continues outputting to LaTeX Table printer
2024-01-19T17:58:21+01:00
Michael Zikeli
Add continues outputting to LaTeX Table printer
The header `LaTeX/Table.hpp` provides the possibility to log rows of a tabulated `.dat` file that can later be used to, e.g. print graphs with pgfplots or also just tables in LaTeX.
This MR introduces a `writeUpdate` Method, that allows...
The header `LaTeX/Table.hpp` provides the possibility to log rows of a tabulated `.dat` file that can later be used to, e.g. print graphs with pgfplots or also just tables in LaTeX.
This MR introduces a `writeUpdate` Method, that allows for intermediate printing of the tables rows, that have not been printed yet, instead of printing the entire table all the time.
Michael Zikeli
Michael Zikeli
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/671
Enable float16 support for the P1 functionspace
2024-02-13T18:29:24+01:00
Michael Zikeli
Enable float16 support for the P1 functionspace
HyTeG was not able to work with float16 types. This merge request fixes this by adding the missing functionality for the P1 functionspace.
Necessary changes:
- [x] Template and explicit instantiate the following kernels that have been ...
HyTeG was not able to work with float16 types. This merge request fixes this by adding the missing functionality for the P1 functionspace.
Necessary changes:
- [x] Template and explicit instantiate the following kernels that have been generated at some point <add, apply, assign, communicate>. The other two kernel types <GS and SOR> have not been templated yet, since they are not used for the generated operators.
- [x] Set standard to C++23 if half precision support is enabled, otherwise some basic asserts like `is_floating_point` will fail.
- [x] Add test that check if all necessary functionality of float16 is working properly.
- [x] Update walberla to support float16 support.
- [x] Make sure that `WALBERLA_BUILD_WITH_HALF_PRECISION_SUPPORT` is enabled in the pipeline.
- [x] Make sure that the remote on the submodule walberla is the walberla repo and not a local fork.
- [x] Test the implementation and float16SupportTest for older compilers as well.
- [x] Some of the now templated kernels use copy by value, while reference is sufficient. Go back and add references.
- [x] Update the license in the modified files.
---
This merge request is dependent on the walberla merge request [!643](https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/643).
Michael Zikeli
Michael Zikeli
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/659
Eigen sparse solver wrapper
2024-02-12T18:33:32+01:00
Nils Kohl
Eigen sparse solver wrapper
To be introduced after !658.
To be introduced after !658.
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/658
Eigen sparse matrix and vector assembly (proxies and helper) from HyTeG's FE operators functions.
2023-11-09T10:07:10+01:00
Nils Kohl
Eigen sparse matrix and vector assembly (proxies and helper) from HyTeG's FE operators functions.
See #233
Solver wrappers still left to be implemented.
See #233
Solver wrappers still left to be implemented.
Nils Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/657
Include multiple-precision floating-point library MPFR to HyTeG
2023-11-06T12:38:45+01:00
Michael Zikeli
Include multiple-precision floating-point library MPFR to HyTeG
MPFR is a C library for simulating arbitrary whole number precision for floating-point variables, hence enabling multiple-precision floating-point computations with correct rounding. The precision requested by the user is the number of b...
MPFR is a C library for simulating arbitrary whole number precision for floating-point variables, hence enabling multiple-precision floating-point computations with correct rounding. The precision requested by the user is the number of bits used to represent the mantissa.
For more information about MPFR compare: [mpfr.org](http://www.mpfr.org/)
For better usage in HyTeG, two external C++ wrapper libraries are included as well to enable e.g. operator overloading, automatic memory management, ...
One of these is using compile time definition of the variable precision. Compare the distributor website: [mpfr::real<>](http://chschneider.eu/programming/mpfr_real/)
The other one uses a runtime definition of the variable precision. Compare the distributor website: [mpfr::mpreal](http://www.holoborodko.com/pavel/mpfr/)
Dominik Thoennes
dominik.thoennes@fau.de
Dominik Thoennes
dominik.thoennes@fau.de
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/653
Particles
2023-10-19T12:20:24+02:00
Nils Kohl
Particles
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 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 Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/649
Draft: To GeometryMap add a method to compute second derivatives
2024-02-29T09:46:16+01:00
Marcus Mohr
Draft: To GeometryMap add a method to compute second derivatives
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.
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 Burkhart
Andreas Burkhart
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/642
First version of parallel PrimitiveStorage setup from file.
2023-10-23T13:54:07+02:00
Nils Kohl
First 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 Kohl
Nils Kohl
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/635
Enhance functionality of FEFunctionRegistry and FunctionMultiStore
2023-07-28T14:21:17+02:00
Marcus Mohr
Enhance functionality of FEFunctionRegistry and FunctionMultiStore
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...
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 Mohr
Marcus Mohr
https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/634
Allow to remove functions from an FEFunctionRegistry or FunctionMultiStore object
2023-07-27T17:22:53+02:00
Marcus Mohr
Allow to remove functions from an FEFunctionRegistry or FunctionMultiStore object
The implementation of this feature touches on issues #172 and #186.
The implementation of this feature touches on issues #172 and #186.
Marcus Mohr
Marcus Mohr