hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2024-03-28T10:34:38+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/257Potential tutorial folder structure2024-03-28T10:34:38+01:00Ponsuganth Ilangovan Ponkumar IlangoPotential tutorial folder structureThis issue is to discuss modifying the tutorials folder structure to make it well categorised, like basics, full apps, etc. As we would also like to have the benchmark apps like Blankenbach under the tutorials which would serve as an exa...This issue is to discuss modifying the tutorials folder structure to make it well categorised, like basics, full apps, etc. As we would also like to have the benchmark apps like Blankenbach under the tutorials which would serve as an example of community standard geophysical application.
A potential folder structure would be,
- Tutorials
- Basics
- 01_PrimitiveStorage
- 02_PrimitiveData
- 03_Communication
- 04_Indexing
- Benchmarks
- 13_Blankenbach
- Full Apps
- others
Any suggestions or improvement with this and maybe also ideas for more tutorials would be greatly helpful as we start to work on these now.Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/253Scaled Apply + GEMV2024-03-08T08:26:10+01:00Nils KohlScaled Apply + GEMVThe proposal of scaled operators in !703 initiated this issue.
Having the standard BLAS level 2 routine `gemv` (see e.g. [here](https://spec.oneapi.io/versions/latest/elements/oneMKL/source/domains/blas/gemv.html))
```math
y \gets \alph...The proposal of scaled operators in !703 initiated this issue.
Having the standard BLAS level 2 routine `gemv` (see e.g. [here](https://spec.oneapi.io/versions/latest/elements/oneMKL/source/domains/blas/gemv.html))
```math
y \gets \alpha A x + \beta y
```
as part of the `Operator` interface would be great for obvious reasons.
What we currently can do is
```math
y \gets A x + \gamma y
```
where $\gamma \in \{0, 1\}$ (a.k.a., `Replace` and `Add`).
Implementing the full `gemv` would be the optimal fix, however, since many of the matrix-free operator implementations work in an "additive" fashion (particularly all elementwise operators including the new generated versions) I do not see an obvious way around having to touch $y$ (i.e., the "dst" vector) *twice* to apply scaling with $\beta$. If there is no obvious solution, we are forced to first scale $y$ (if $\beta \neq 0$) and then perform a scaled matrix-vector multiplication after that. We can do this scaling of $y$ inside the operator, but I do not see a real reason to do that inside the operator and not just call `assign` beforehand.
MR !703 proposes an implementation that enables scaled operators
```math
y \gets \alpha A x + \gamma y
```
that is in my opinion not optimal since $\alpha$ becomes part of the operator's state.
To resolve the "state"-issue mentioned above, I propose to actually extend the `apply` routine by a parameter $\alpha$ instead of changing the operator's state:
```
virtual void apply( const ValueType& alpha // new parameter
const SourceFunction& src,
const DestinationFunction& dst,
size_t level,
DoFType flag,
UpdateType updateType = Replace ) const
```
Refactoring this requires some work, but should hopefully be doable. I'd keep the current apply, and just make it call the new one with $\alpha = 1$.
-----
EDIT: We basically already do this:
> We can do this scaling of $y$ inside the operator, but I do not see a real reason to do that inside the operator and not just call `assign` beforehand.
if `UpdateType == Replace` since we [interpolate `0`](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/0a8460a3dd538d9d91a194b5d5588c1a4ef2b1ac/src/hyteg/elementwiseoperators/P1ElementwiseOperator.cpp#L96).
Therefore, for completeness I'll also propose an interface for the `gemv`:
```
virtual void gemv( const ValueType& alpha // new parameter
const SourceFunction& src,
const ValueType& beta // new parameter
const DestinationFunction& dst,
size_t level,
DoFType flag ) const
```
with the perk that it gets rid of the `UpdateType` parameter.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/244Shadowing makes pipeline fail with FOG operators in app directory2024-02-13T16:33:09+01:00Marcus MohrShadowing makes pipeline fail with FOG operators in app directoryHi,
I am encountering pipeline failure due to shadowing variable declarations in case of a generated operator placed inside an app's directory:
```
../../../apps/nlDiffusion/P1ElementwiseNonlinearDiffusionNewtonGalerkin.cpp:971:26: erro...Hi,
I am encountering pipeline failure due to shadowing variable declarations in case of a generated operator placed inside an app's directory:
```
../../../apps/nlDiffusion/P1ElementwiseNonlinearDiffusionNewtonGalerkin.cpp:971:26: error: declaration shadows a local variable [-Werror,-Wshadow]
const real_t tmp_7_WHITE_UP = tmp_6_WHITE_UP * 0.050086823222829389;
^
```
See e.g. pipeline [#62046](https://i10git.cs.fau.de/hyteg/hyteg/-/pipelines/62046)Fabian BöhmFabian Böhmhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/241Uniform way to apply all GeometryMap subclasses to the SetupStorage2024-01-24T11:24:55+01:00Nils KohlUniform way to apply all GeometryMap subclasses to the SetupStorageThe application of a GeometryMap to all primitives currently works differently for each type/subclass.
Most maps implement a static method `setMap( ... )` that does that. However, the signature is always different which makes the select...The application of a GeometryMap to all primitives currently works differently for each type/subclass.
Most maps implement a static method `setMap( ... )` that does that. However, the signature is always different which makes the selection of a map during run time annoying. Some examples:
* [IcosahedralShellMap::setMap()](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/7d4e5176463d7fa5e7c3391fc1d56f30a2aa83ce/src/hyteg/geometry/IcosahedralShellMap.hpp#L239)
* [TokamakMap::setMap()](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/7d4e5176463d7fa5e7c3391fc1d56f30a2aa83ce/src/hyteg/geometry/TokamakMap.hpp#L357)
* [CircularMap](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/7d4e5176463d7fa5e7c3391fc1d56f30a2aa83ce/src/hyteg/geometry/CircularMap.hpp) does not even have that method.
The procedure then usually goes as follows:
```
SetupPrimitiveStorage setupStorage( meshInfo, numProcesses );
// Different call for all maps
AnnulusMap::setMap( setupStorage );
```
Would be nice if we could do something like this:
```
void createStorage( std::shared_ptr< GeometryMap > someMap )
{
SetupPrimitiveStorage setupStorage( meshInfo, numProcesses );
// Same call for all maps.
someMap->setMap( setupStorage );
}
```
Is there any reason `setMap()` cannot be a virtual method in the `GeometryMap` class? Maybe I am missing something.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/201Update GMG tutorial2023-02-17T14:32:07+01:00Nils KohlUpdate GMG tutorialThe GMG tutorial (05) is a little outdated and could use some more in-depth description to provide a nice starting point for new users.The GMG tutorial (05) is a little outdated and could use some more in-depth description to provide a nice starting point for new users.Nils KohlNils Kohl