hyteg issueshttps://i10git.cs.fau.de/groups/hyteg/-/issues2023-10-19T12:10:36+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/231ADIOS2 output for unresolved particles.2023-10-19T12:10:36+02:00Nils KohlADIOS2 output for unresolved particles.(See also discussion in https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/653#note_25667.)
ADIOS2 output is currently not supported for the unresolved particle feature. Either this has to be implemented as part of MESA-PD or through...(See also discussion in https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/653#note_25667.)
ADIOS2 output is currently not supported for the unresolved particle feature. Either this has to be implemented as part of MESA-PD or through the coupling on the HyTeG side. I suppose the latter is simpler, but not sure yet.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/229VTK output is not possible for functions in single precision2024-01-16T13:40:33+01:00Michael ZikeliVTK output is not possible for functions in single precisionWhile writing VTK output, functions that have another type than double precision are simply skipped and only the mesh structure and the functions of double or integer type are printed. There is no user notification, that this is done, th...While writing VTK output, functions that have another type than double precision are simply skipped and only the mesh structure and the functions of double or integer type are printed. There is no user notification, that this is done, the function values are just missing in the output file.
A possible workaround is to use the `.copyfrom()` member function to create a printable copied function object of value type double, however this works only for P1 functions.
Allowing VTK output for any precision (e.g. single, half, ...) would be a nice to have.Michael ZikeliMichael Zikelihttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/228AdiosWriterTest fails with old ICC2023-09-15T09:52:04+02:00Marcus MohrAdiosWriterTest fails with old ICCActivating ADIOS tests in the pipeline, see MR !645 revealed a [problem](https://i10git.cs.fau.de/hyteg/hyteg/-/jobs/1118381) with the `AdiosWriterTest`. It fails for ICC 2022, but only for that one.Activating ADIOS tests in the pipeline, see MR !645 revealed a [problem](https://i10git.cs.fau.de/hyteg/hyteg/-/jobs/1118381) with the `AdiosWriterTest`. It fails for ICC 2022, but only for that one.Implement basic Checkpointing FunctionalityMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/226Check for which Function Families a Copy Assignment Operator needs to be impl...2023-08-01T07:54:34+02:00Marcus MohrCheck for which Function Families a Copy Assignment Operator needs to be implementedSee discussion in #224 the origin of this issue.See discussion in #224 the origin of this issue.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/222Problem with exporting DG functions to VTK2023-10-05T17:03:55+02:00Marcus MohrProblem with exporting DG functions to VTKWe seem to have missed the introduction of a regression in the pipeline. Running `VTKOutputTest` on the current master works, but the resulting files for P0, DG1, P1DGE are invalid. The connectivity is either screwed up or so wrong that ...We seem to have missed the introduction of a regression in the pipeline. Running `VTKOutputTest` on the current master works, but the resulting files for P0, DG1, P1DGE are invalid. The connectivity is either screwed up or so wrong that ParaView simply crashes.
The files for CG functions appear to be fine, though.
We need a better way to automatically verify that we cannot only write files, but also that their contents make sense.
I also added assertions to
- ```VTKMeshWriter::writeCells2D()```
- ```VTKMeshWriter::writeCells3D()```
to at least ensure that the node indices in the connectivity list are not exceeding the number of nodes we write to the file. See
https://i10git.cs.fau.de/hyteg/hyteg/-/pipelines/53914.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/218Order of scalar coefficient parameters in form constructors is inconsistent2023-06-19T15:37:15+02:00Daniel BauerOrder of scalar coefficient parameters in form constructors is inconsistentSeveral forms take as constructor arguments a scalar coefficient (`std::function< real_t ( const Point3D & ) >`) both for 2D and for 3D.
The order of the two parameters is different among the forms:
<details><summary>
`rg "> _callback_...Several forms take as constructor arguments a scalar coefficient (`std::function< real_t ( const Point3D & ) >`) both for 2D and for 3D.
The order of the two parameters is different among the forms:
<details><summary>
`rg "> _callback_Scalar_Variable_Coefficient_2D_k"`
</summary>
```
src/hyteg/forms/form_hyteg_generated/p2/p2_sqrtk_mass_affine_q6.hpp: p2_sqrtk_mass_affine_q6( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_sqrtk_mass_affine_q4.hpp: p2_sqrtk_mass_affine_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_k_mass_affine_q4.hpp: p2_k_mass_affine_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_linear_form_blending_q7.hpp: p2_linear_form_blending_q7( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_invk_mass_affine_q6.hpp: p2_invk_mass_affine_q6( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_div_k_grad_affine_q4.hpp: p2_div_k_grad_affine_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_linear_form_affine_q6.hpp: p2_linear_form_affine_q6( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p2/p2_div_k_grad_blending_q4.hpp: p2_div_k_grad_blending_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p0/p0_linear_form_blending_q5.hpp: p0_linear_form_blending_q5( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p0/p0_linear_form_blending_q7.hpp: p0_linear_form_blending_q7( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_k_mass_affine_q4.hpp: p1_k_mass_affine_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_invk_mass_affine_q4.hpp: p1_invk_mass_affine_q4( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_linear_form_blending_q5.hpp: p1_linear_form_blending_q5( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_div_k_grad_blending_q3.hpp: p1_div_k_grad_blending_q3( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_div_k_grad_affine_q3.hpp: p1_div_k_grad_affine_q3( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k )
src/hyteg/forms/form_hyteg_generated/p1/p1_linear_form_affine_q6.hpp: p1_linear_form_affine_q6( std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_2D_k, std::function< real_t ( const Point3D & ) > _callback_Scalar_Variable_Coefficient_3D_k )
```
</details>
This is problematic since both parameters have the same type, so that the compiler can not assist us in passing them in the correct order.
The cause of this remains to be investigated.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/216Doxygen Documentation2024-03-20T10:39:17+01:00Marcus MohrDoxygen DocumentationHi,
I was just parsing the output of running Doxygen on our master. One thing I recognised is the following
# \section
In the tutorials we make use of Doxygen's [`\section` command](https://www.doxygen.nl/manual/commands.html#cmdsectio...Hi,
I was just parsing the output of running Doxygen on our master. One thing I recognised is the following
# \section
In the tutorials we make use of Doxygen's [`\section` command](https://www.doxygen.nl/manual/commands.html#cmdsection). Please be aware that the name given to a section is **global**. Thus, we get warnings like the following:
```
Preprocessing .../HyTeG/tutorials/08_CahnHilliard/CahnHilliard.cpp:478: warning: multiple use of section label 'code' while adding section, (first occurrence: .../HyTeG/tutorials/01_PrimitiveStorage.cpp, line 101)
```
This actually has also a real effect. The corresponding section in tutorial \#8 bares the name *Complete Program* as specified in tutorial \#1 and not the name *Code* as given in tutorial \#8.
I suggest to prefix the section names in the tutorials with **`T<tutorial number>-`** to make section names unique.
# $`\LaTeX`$
Do not add pseudo-LaTeX code such as,
```
/// Evaluates the linear functional
///
/// l( v ) = \int_\Omega f * v
///
```
but instead put it into a construct to render it as $`\LaTeX`$:
```
/// Evaluates the linear functional
/// \f[
/// l( v ) = \int_\Omega f \cdot v
/// \f]
```
Also make sure that your $`\LaTeX`$ commands are supported by standard $`\LaTeX`$. Otherwise you will get problems.
While additional packages can be loaded by Doxygen via the `EXTRA_PACKAGES` option, we should IMHO limit this to the really essential stuff for reasons of portability. Currently we only load **amsmath** in this way.
Note, however, that Doxygen seems not so super stable w.r.t. to treating $`\LaTeX`$. For example that following
```
* \f{align*}{
* F(\phi) = \int \boldsymbol \psi(\phi) dx + \frac{\epsilon^2}{2}\int |\nabla \phi |^2 dx
* \f}
```
seems to be responsible for
```
warning: Found unknown command '\boldsymbol'
warning: Found unknown command '\psi'
```
although it is type-set correctly in the output and (at least to me) seems to adhere to the specification.
# Other Issues
Most other warnings seem to belong to one of four categories:
- `The following parameter of XYZ is not documented:`, which would be easy to fix by adding the respective documentations. Unless XYZ is a templated function. I see cases where there is an attempt to document the parameter, but Doxygen seems to have problems to understand this for a concrete template instantiation. Not sure if one can help Doxygen here.
- `warning: no uniquely matching class member found for XYZ` which, without looking too much into details seems to be related to templatisation and, thus, might be unfixable.
- `warning: explicit link request to 'XYZ' could not be resolved`, where XYZ is something like P1Function or ValueType, so again related to templatisation.
- `warning: member XYZ belongs to two different groups. The second one found here will be ignored.` Not sure about that one, yet.
# Pictures
This is more of a question. Can someone please explain to me, why we need to explicitely add pictures, used e.g. in the tutorials, to `EXTRA_HTML_FILES` when we include them using `<img src="..."/>`? This only seems to bother Doxygen, when we [build the documentation as part of the pipeline](https://i10git.cs.fau.de/hyteg/hyteg/-/jobs/1076187), but not, when one builds it locally. What's the difference and could that maybe be resolved?Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/214Add documentation to grid transfer functions2023-12-19T17:21:34+01:00Nils KohlAdd documentation to grid transfer functionsFor instance the standard restriction classes are the transpose of the prolongation - but users might think that it is rather an "interpolation". We need better names and documentation.For instance the standard restriction classes are the transpose of the prolongation - but users might think that it is rather an "interpolation". We need better names and documentation.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/2132D solutions in 3D tests2023-06-22T15:17:02+02:00Fabian Böhm2D solutions in 3D testsI stumbled across a series of tests where 3D meshes were tested with only 2-dimensional solutions e.g. https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/tests/hyteg/convergence/P1ElementwiseCGConvergenceTest.cpp . This doesn't matter in...I stumbled across a series of tests where 3D meshes were tested with only 2-dimensional solutions e.g. https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/tests/hyteg/convergence/P1ElementwiseCGConvergenceTest.cpp . This doesn't matter in hindsight as the solvers are used in practice on 3D problems and work. I will add 3D solutions in these tests.Fabian BöhmFabian Böhmhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/212Incorporation of weak Dirichlet boundary conditions in test cases2024-02-20T09:55:24+01:00Fabian BöhmIncorporation of weak Dirichlet boundary conditions in test casesCurrently, the application of weak boundary conditions from the user view in a test case is complicated:
- in HyTeG solvers, the DoFtype has to be set to 'All' via solver.setDoFType( All ); because the DoFs on the boundary are now par...Currently, the application of weak boundary conditions from the user view in a test case is complicated:
- in HyTeG solvers, the DoFtype has to be set to 'All' via solver.setDoFType( All ); because the DoFs on the boundary are now part of the solution
- the standard strong boundary application has to be switched off in PETSc solvers by solver.disableApplicationBC( true );
- the user can/has to set the penalty depending on his application and operator (ensure coercivity of the operator: e.g. larger constant required in 3D)
Two ways to avoid giving the responsibility to do these small yet crucial operations to the user are:
- Inspecting the given operator within the solver and set DoFs and boundary handling according to the operator type (if it applies its BCs weakly)
(con: it is not the solver's responsibility to check how BCs should be applied but the operator's, the solver should 'just solve')
- introducing another boundary flag WeakDirichletBC and handling the case similarly to the existing free slip BC.
(con: additional functions for the new boundary flag would have to be implemented, and the boundary has to be set with the new flag at the start of the test case
pro: IMO intuitive way to handle weak BCs, no modifications in the solvers)
Are there other/better ideas to handle this?https://i10git.cs.fau.de/hyteg/hyteg/-/issues/210VTKOutput for N1E1Function fails in case of non-FP ValueType2023-04-27T16:32:16+02:00Marcus MohrVTKOutput for N1E1Function fails in case of non-FP ValueTypeHi,
I just extended the `VTKOutputTest` to include all the new function classes for which VTKWriters had been implemented:
- P0Function
- DG1Function
- EGFunction
- N1E1VectorFunction
The test checks that we can compile and execute cod...Hi,
I just extended the `VTKOutputTest` to include all the new function classes for which VTKWriters had been implemented:
- P0Function
- DG1Function
- EGFunction
- N1E1VectorFunction
The test checks that we can compile and execute code for exporting scalar and/or fields over $`\mathbb{R}`$ represented by these functions, i.e. when the `ValueType` of the template is `real_t`. Additionally it also checks whether we can export function objects where `ValueType` is `int32_t` and `int64_t`.
In the case of the `N1E1VectorFunction` class the integer part fails, because `N1E1VectorFunction::communicate()` aborts for non-FP types.
```
if constexpr ( !std::is_floating_point< ValueType >::value )
{
WALBERLA_ABORT(
"This function flips the signs of unknowns to accommodate for inconsistent edge orientations. Do not use it to communicate index vectors. Use getDoFs()->communicate instead!" )
}
```
Admittedly, exporting integer fields is not a feature that is much sought after. However, it can be helpful e.g. in inspecting whether our DoF enumerations work correctly. Actually this is the way the test sets up the fields.
I am not overly familiar with the implementation details of `N1E1VectorFunction`. However, the abort message suggest that there is a workaround. Would it be possible to have `communicate()` use that workaround instead of aborting in case of non-FP types?
Cheers
MarcusDaniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/207Minor DG tutorial fixes2023-05-26T15:34:21+02:00Nils KohlMinor DG tutorial fixesThere are some minor things that should be fixed in the DG tutorial.
* The full app code is missing on the Doxygen page.
* The computation of h is flawed. Better use h_max or h_min. There are suitable functions in HyTeG.There are some minor things that should be fixed in the DG tutorial.
* The full app code is missing on the Doxygen page.
* The computation of h is flawed. Better use h_max or h_min. There are suitable functions in HyTeG.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/205Transfer methods of P2Function class only work in 2D2023-12-19T17:12:59+01:00Marcus MohrTransfer methods of P2Function class only work in 2DAll of the following member functions of the `P2Function` class are missing implementations for macro-cells and, thus, only work in 2D (or with surfaces):
- `restrictInjection()`
- `prolongateP1ToP2()`
- `restrictP2ToP1()`
However, the...All of the following member functions of the `P2Function` class are missing implementations for macro-cells and, thus, only work in 2D (or with surfaces):
- `restrictInjection()`
- `prolongateP1ToP2()`
- `restrictP2ToP1()`
However, they currently do not even abort, when the PrimitiveStorage has global cells.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/203P1WrapperForm does not work with HFG forms2023-03-21T11:11:01+01:00Marcus MohrP1WrapperForm does not work with HFG formsHi,
the `P1WrapperForm` assumes that the form around which it wraps itself provides a method `integrate()` which returns from a single row of the local element matrix the entries associated with vertex dofs. So a highly specialised meth...Hi,
the `P1WrapperForm` assumes that the form around which it wraps itself provides a method `integrate()` which returns from a single row of the local element matrix the entries associated with vertex dofs. So a highly specialised method with a very generic name. Our FEniCS forms
- P1FenicsFrom *(here it is, naturally, just the computation of a single row)*
- P1ToP2FenicsForm *(again just a single matirx row)*
- P2FenicsForm *(only part of row)*
- P2ToP1FenicsForm *(only part of row)*
implement this.
The forms generated by HFG do not provide that functionality. Here we (only) have the method `integrateRow0()` to return an invidiual row of the element matrix. Thus, the `P1WrapperForm` cannot be compiled together with any HyTeG-form, but only together with FEniCS-forms.
Consequently all operators that depend on it cannot be compiled with HyTeG-forms either, such as e.g.
- `P1ConstantOperator`
- `P1ToP2ConstantOperator`
This is related to the still open problem of streamlining naming and interfaces of our forms/integration routines, see also #84, #145, #158.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://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 Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/199Geometric Multigrid solver changes b/f on lower levels2023-02-14T10:16:05+01:00Dominik Thoennesdominik.thoennes@fau.deGeometric Multigrid solver changes b/f on lower levelsThe geometric multigrid solver currently changes the right hand side (f/b) on lower levels. Not the one that is passed to `solve(...)`
This might lead to unexpected results in the application.
Otherwise another temporary function must be...The geometric multigrid solver currently changes the right hand side (f/b) on lower levels. Not the one that is passed to `solve(...)`
This might lead to unexpected results in the application.
Otherwise another temporary function must be created or passed to the solver.
https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/src/hyteg/solvers/GeometricMultigridSolver.hpp#L194https://i10git.cs.fau.de/hyteg/hyteg/-/issues/198Bad error metric in some 1:1 function comparison tests2023-02-07T13:35:02+01:00Nils KohlBad error metric in some 1:1 function comparison testsSome tests apply a bad error metric to check whether two functions are equal.
For example this applies here:
https://i10git.cs.fau.de/hyteg/hyteg/-/blob/5a581562882693eaa56d8ea24a8196c152485721/tests/hyteg/P1/P1PetscApplyTest.cpp#L106
...Some tests apply a bad error metric to check whether two functions are equal.
For example this applies here:
https://i10git.cs.fau.de/hyteg/hyteg/-/blob/5a581562882693eaa56d8ea24a8196c152485721/tests/hyteg/P1/P1PetscApplyTest.cpp#L106
```
const auto absScalarProd = std::abs( err.dotGlobal( ones, level, location ) );
WALBERLA_CHECK_LESS( absScalarProd, eps );
```
But the test could pass even if the error is large, if it just alternates at each point for instance. That is unlikely, but extremely misleading once it happens. Rather we should use the 2- or inf-norm here.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/197readd petsc+trilinos tests for intel2023-01-27T09:18:47+01:00Dominik Thoennesdominik.thoennes@fau.dereadd petsc+trilinos tests for intelThe petsc and trilinos test are currently disabled for the "old" intel compilers
This has to be fixed in the docker images firstThe petsc and trilinos test are currently disabled for the "old" intel compilers
This has to be fixed in the docker images firsthttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/195Sort out usage of namespaces2023-10-06T18:35:43+02:00Marcus MohrSort out usage of namespacesHi,
since I plan to close #158 now, I am adding here an issue that Nils, I guess, brought up then:
> ccd5f369 inspired me in adding a row here. Namespaces are all over the place, we may want to have that sorted out (i.e. only single na...Hi,
since I plan to close #158 now, I am adding here an issue that Nils, I guess, brought up then:
> ccd5f369 inspired me in adding a row here. Namespaces are all over the place, we may want to have that sorted out (i.e. only single namespace hyteg:: or add some more structure by directories, or something else ...). Our doxygen documentation and IDE code completion would also really benefit.
Cheers
MarcusNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/194Mixed Precision2024-02-08T15:22:55+01:00Dominik Thoennesdominik.thoennes@fau.deMixed Precision# This issue provides an overview for the progress towards mixed precision
- [x] Make `real_t=float` usable.
Nils and Dominik decided to exclude the "old", stencil generated kernels for this task since these are hard-coded to double.
...# This issue provides an overview for the progress towards mixed precision
- [x] Make `real_t=float` usable.
Nils and Dominik decided to exclude the "old", stencil generated kernels for this task since these are hard-coded to double.
- [x] Create an app/test that uses functions with `double` and `float` and has a assign/copy function to couple them
- [ ] Optimize the hand-written vector-vector operations (such as `assign`, `add`, etc.) and get rid of their generated counterparts since we do not really need to have those generated, even for performance.
- [ ] Couple the hfg with pystencils to generate a "full" operator class. This should firstly contain the `apply` function
See also #164