hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2024-03-18T13:03:20+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/718Integrating Stokes solvers from branch burk/ELWMS.2024-03-18T13:03:20+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/716Draft: GEMV2024-03-12T14:39:21+01:00Nils KohlDraft: GEMVThis 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 KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/707Draft: Adding tool for temperature initialisation2024-03-14T11:13:40+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/601Draft: Access to individual DoFs2023-05-24T15:56:56+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 Mohr