hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2023-07-31T14:02:31+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/186Rule-of-three for Functions2023-07-31T14:02:31+02:00Nils KohlRule-of-three for FunctionsFunctions only carry handles to access the allocated memory that resides on the Primitives.
In some sense the memory is owned by the Primitives. Currently destroying functions does not deallocate all of the data that was allocated before...Functions only carry handles to access the allocated memory that resides on the Primitives.
In some sense the memory is owned by the Primitives. Currently destroying functions does not deallocate all of the data that was allocated before.
This requires the implementation of custom destructors. So we should also implement copy-constructors and copy-assignment operators for all functions (https://en.cppreference.com/w/cpp/language/rule_of_three).
Copy constructors are relevant anyway (see #172 - although copy-constructors might not fix all problems related to solvers) and it is often misleading that Functions are not destroyed when leaving scope.
It is not clear to me whether introducing will break stuff - but on the other hand that would be a bad sign anyway.
What is missing?
* methods to remove data from Primitives
* destructors in all Function classes
* copy-constructors in all Function classes
* copy-assignment operators in all Function classesNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/192Remove assemble[23]D() and assembly[23]DDefined() functions from forms2023-05-26T16:53:56+02:00Daniel BauerRemove assemble[23]D() and assembly[23]DDefined() functions from formsThe `Form` class requires that all derived classes implemented the functions mentioned in the title.
However, these functions are never used except for the cases listed below:
```
# rg "(assemble[23]D|assembly[23]DDefined)"
src/hyteg/m...The `Form` class requires that all derived classes implemented the functions mentioned in the title.
However, these functions are never used except for the cases listed below:
```
# rg "(assemble[23]D|assembly[23]DDefined)"
src/hyteg/mixedoperators/EdgeDoFToVertexDoFOperator/EdgeDoFToVertexDoFOperator.cpp
96: if ( form_.assemble3D() )
112: if ( form_.assemble2D() )
src/hyteg/mixedoperators/VertexDoFToEdgeDoFOperator/VertexDoFToEdgeDoFOperator.cpp
84: if ( form_.assemble3D() )
98: if ( form_.assemble2D() )
src/hyteg/edgedofspace/EdgeDoFOperator.cpp
85: if ( form_.assemble3D() )
94: if ( form_.assemble2D() )
…
```
In the above cases, these checks do not have a real value since the code is already guarded by checks like `this->getStorage()->hasGlobalCells()`.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/164Trying to use single or mixed precision2023-04-05T11:20:38+02:00Marcus MohrTrying to use single or mixed precisionHi,
in issue #158 the conjecture was made that trying to compile with ```real_t = float``` would break many things. Guess what, that's true :wink:. Below are some of the issues I extracted from the zillions of warnings/errors:
- There ...Hi,
in issue #158 the conjecture was made that trying to compile with ```real_t = float``` would break many things. Guess what, that's true :wink:. Below are some of the issues I extracted from the zillions of warnings/errors:
- There are many warnings on narrowing conversions ```conversion to ‘walberla::real_t {aka float}’ from ‘double’ may alter its value [-Wfloat-conversion]``` as we do not consistently make use of ```real_c()``` and have many double literals in the code.
- A major problem is that all the FEniCS forms are generated for double. Thus, we cannot call ```gen.tabulate_tensor()``` and pass it an array of floats.
- But also in HyTeG itself the generated kernels seem to all use double.
- Some things also get explicitly instantiated only for double, like e.g. ```EdgeDoFPackInfo```. But I did not look deeper into this.
With respect to *mixed precision* I also attempted to instantiate a ```VectorDoFFunction<float>``` while compiling with ```real_t = double```. That at least compiles, but the linker cannot satisfy all dependencies. Likely here we would need to explicitly instantiate other stuff for ```float``` then, too. Like e.g. ```float hyteg::generateZero<float>()```.
Cheers
Marcushttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/158Topics for Refactoring Week2023-04-05T11:16:40+02:00Marcus MohrTopics for Refactoring WeekHi,
I thought it might be a good idea to start collecting topics for the planned code refactoring. Please feel free to extend this.
Cheers
Marcus
| topic | comment/explanation | related issues |
| ------ | ------ | ----- |
| forms i...Hi,
I thought it might be a good idea to start collecting topics for the planned code refactoring. Please feel free to extend this.
Cheers
Marcus
| topic | comment/explanation | related issues |
| ------ | ------ | ----- |
| forms interface | in order to better be able to exchange forms we should clean-up and reduce the number of different ```integrate()```, ```integrateAll()```, ```integrateRow()```, ```integrateRow0()``` methods and discuss whether the various ```assemble2D()``` methods are still required | #84, #92, #145 |
| ~~forms deprecation~~ | we should get rid of the remaining forms in **form_hyteg_manual** and the old **form_hyteg_generated** forms that are not from HFG | #153 |
| ~~matrix creation~~ | implement matrix creation for the new vector and block operators and streamline the whole approach | #110, #125 |
| P1-3D-Stencil-Assembly | see issue | #115 |
| ~~culling of P1Operators~~ | decide which of these operators should be supported and which removed: <ul><li>P1ConstantOperator</li><li>P1ConstantOperator_new</li><li>P1PointwiseOperator</li><li>P1PolynomialBlendingOperator</li><li>P1SurrogateOperator</li><li>P1VariableOperator</li><li>P1VariableOperator_new</li></ul>| #165
| namespaces | ccd5f3694ed16ae2386803601596343f8921548b 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. | #195 |
| ~~DGFunction~~ | decide what to do with this class; the problem IMHO is that it has deviated significantly from e.g. VertexDoFFunction or EdgeDoFFunction w.r.t. supported functionality; also it seems to only support 2D | none |
| ~~PetscInt~~ | we should not use PetscInt outside of any code that is explicitly Petsc-related (e.g. for numerators in apps), I think we can replace it by in64_t or similar and then cast to PetscInt later | #125, #161 |
| ~~real_t to float~~ | pretty sure that mapping real_t to float breaks many things | #164, #194 |
| ~~branch cleanup~~ | we should try to cleanup some of the old branches that are still in the repo | none |Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/170Rename dotGlobal() to dot()2023-03-17T15:37:52+01:00Nils KohlRename dotGlobal() to dot()Should generally be "global" for users, shouldn't it?Should generally be "global" for users, shouldn't it?https://i10git.cs.fau.de/hyteg/hyteg/-/issues/181Replace PointND and Matrix classes2023-03-16T16:53:32+01:00Marcus MohrReplace PointND and Matrix classesThis is a follow-up and continues the discussion from issue #101. HyTeG offers two auxilliary classes
- `template < typename T, uint_t M, uint_t N > class Matrix`
- `template<typename T, size_t N> class PointND`
for small dense vectors ...This is a follow-up and continues the discussion from issue #101. HyTeG offers two auxilliary classes
- `template < typename T, uint_t M, uint_t N > class Matrix`
- `template<typename T, size_t N> class PointND`
for small dense vectors and matrices. We would like to replace these by something that is better tested and (potentially) offers more functionality.
We are currently in favour of using Eigen for this. However, there is the issue that *THE_INDEX_TYPE_MUST_BE_A_SIGNED_TYPE* in Eigen, while our classes currently expect indices of type `uint_t`.Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/190Prepare removal of DGFunction_old2023-02-13T18:23:49+01:00Marcus MohrPrepare removal of DGFunction_oldHi,
I am adding this issue to remind us that we should work on the removal of the old DG function implementation. This would mostly be everything related to the code inside:
- `dgfunctionspace_old`
- `facedofspace_old`
Note the *depre...Hi,
I am adding this issue to remind us that we should work on the removal of the old DG function implementation. This would mostly be everything related to the code inside:
- `dgfunctionspace_old`
- `facedofspace_old`
Note the *deprecation postfix* :wink:. As we have a new more flexible implementation in the master there should hopefully not be too much porting needed to get rid of the old stuff.
As far as I see it is only the following three apps that still depend on it, because they use the the `dgfunctionspace_old/DGUpwindOperator`:
- `geophysics_plume.cpp`
- `dg0_transport.cpp`
- `Chorin.cpp`
And of course the associated tests.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/113Interface of interpolate() for composite functions2023-01-12T11:27:41+01:00Marcus MohrInterface of interpolate() for composite functionsHi,
w.r.t. issue #112 I had just been contemplating whether I should also implement multElementwise() for our composite functions, i.e.
- P1StokesFunction
- P2P1TaylorHoodFunction
- P2P2StokesFunction
Looking at their interpolate() me...Hi,
w.r.t. issue #112 I had just been contemplating whether I should also implement multElementwise() for our composite functions, i.e.
- P1StokesFunction
- P2P1TaylorHoodFunction
- P2P2StokesFunction
Looking at their interpolate() methods as an example I decided against it for the moment. Now finally coming to the actual issue. I don't think that the following interface for the method is very useful
````
void interpolate( const std::function< real_t( const hyteg::Point3D& ) >& expr, size_t level, DoFType flag = All ) const
````
as it only allows to initialise all component functions with the same std::function which to me doesn't seem to be a scenario that is required too often. The apps I looked into consequently do not use this method at all, but instead call interpolate() on the component functions which are publicaly accessible. I'd suggest to
do one of the following:
1. Remove this interpolate() method from the composite functions (maybe also the one for a constant value?)
2. Alternatively change the interface of both to accept an std::array of length four
Cheers
MarcusDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/150Update interface of MMOCTransport.step()2023-01-12T11:03:30+01:00Marcus MohrUpdate interface of MMOCTransport.step()Hi,
just a small issue, but as it effects one of the tutorials I wanted to document it. So we don't forget fixing it in a nice way.
The ```step()``` method of the ```MMOCTransport``` class currently has the following interface
```c++
vo...Hi,
just a small issue, but as it effects one of the tutorials I wanted to document it. So we don't forget fixing it in a nice way.
The ```step()``` method of the ```MMOCTransport``` class currently has the following interface
```c++
void step( const FunctionType& c,
const FunctionType& ux,
const FunctionType& uy,
const FunctionType& uz,
const FunctionType& uxLastTimeStep,
const FunctionType& uyLastTimeStep,
const FunctionType& uzLastTimeStep,
const uint_t& level,
const DoFType& flag,
const real_t& dt,
const uint_t& innerSteps,
const bool& resetParticles = true,
const bool& globalMaxLimiter = true,
const bool& setParticlesOutsideDomainToZero = false )
```
This is our old-school approach to vector functions and does not work well together with the new ```CSFVectorFunction``` class, in the case of a 2D problem. As then there is no third component to pass to ```step()```. The following code line
```
transport.step( c, u.uvw[0], u.uvw[1], u.uvw[2], u.uvw[0], u.uvw[1], u.uvw[2], maxLevel, All, dt, 1, true );
```
let's ```tutorials/07_IsoviscousConvectionAnnulus/IsoviscousConvectionAnnulus``` crash currently when run with the default 2D mesh file.
Going to *hot-fix* the tutorial now, before adressing the issue in a more consistent way.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/188Change Matrix::adj() to Matrix::inverse()2022-11-24T17:07:03+01:00Marcus MohrChange Matrix::adj() to Matrix::inverse()The member function `Matrix::adj()` of our matrix class computes the [adjugate](https://en.wikipedia.org/wiki/Adjugate) of the matrix. This requires the matrix to be square and is currently only implemented for $`2\times2`$ matrices. In ...The member function `Matrix::adj()` of our matrix class computes the [adjugate](https://en.wikipedia.org/wiki/Adjugate) of the matrix. This requires the matrix to be square and is currently only implemented for $`2\times2`$ matrices. In the case the matrix is square and invertible it holds that
```math
\text{adj}(A) = \det(A) A^{-1}
```
I looked through the code and it appears to me that all calls to `Matrix::adj()` are followed by scaling the result with the determinant to obtain the true inverse. Thus, in light of issue #181 and to reduce code duplication (and because *inverse* is a concept more commonly known than *adjugate*) I suggest to replace `Matrix::adj()` with `Matrix::inverse()`.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/146Add parent classes for smoothers2022-08-11T18:09:57+02:00Andreas WagnerAdd parent classes for smoothersIn our meeting today the question was posed, which methods we should include in the abstract Operator interface.
One idea was to include all the smoothing procedures to make it easier to switch between operators and smoothers at runtime...In our meeting today the question was posed, which methods we should include in the abstract Operator interface.
One idea was to include all the smoothing procedures to make it easier to switch between operators and smoothers at runtime. This is currently not possible and since all our operators have different smoothers, changing the operator often requires commenting in large amounts of code to pass compilation, even if the respective code paths are never taken.
This idea was rejected to avoid too much clutter in the base class in the long run and since from an idiomatic point of view a class should be able to implement all the methods of the parent class.
An alternative suggestion was to implement an interface for every smoother type. For the Jacobi, GS and symmetric GS this could look as follows:
```cpp
template < typename Function >
class JacobiSmoothable
{
public:
virtual ~JacobiSmoothable() = default;
virtual void smooth_jac( const Function& dst,
const Function& rhs,
const Function& tmp,
const real_t& relax,
size_t level,
DoFType flag ) const = 0;
};
template < typename Function >
class GSSmoothable
{
public:
virtual ~GSSmoothable() = default;
virtual void smooth_gs( const Function& dst, const Function& rhs, size_t level, DoFType flag ) const = 0;
};
template < typename Function >
class GSBackwardsSmoothable
{
public:
virtual ~GSBackwardsSmoothable() = default;
virtual void smooth_gs_backwards( const Function& dst, const Function& rhs, size_t level, DoFType flag ) const = 0;
};
// ... all the other smoothers ..
```
Operators, which want to support some of the smoothers can then inherit from the respective interfaces.
For a reduced version of the P1ConstantOperator which only support Jacobi and forward GS this could look like this:
```cpp
template < class P1Form, bool Diagonal = false, bool Lumped = false, bool InvertDiagonal = false >
class P1ConstantOperator : public Operator< P1Function< real_t >, P1Function< real_t > >,
public JacobiSmoothable< P1Function< real_t > >,
public GSSmoothable< P1Function< real_t > >
{
public:
void smooth_jac( const P1Function< real_t >& dst,
const P1Function< real_t >& rhs,
const P1Function< real_t >& tmp,
const real_t& relax,
size_t level,
DoFType flag ) const override
{
// implementation ...
}
void smooth_gs( const P1Function< real_t >& dst, const P1Function< real_t >& rhs, size_t level, DoFType flag ) const override
{
// implementation ...
}
};
```
Our solvers can then dynamically at runtime check if the operator supports the given smoother, and throw an exception if this is not the case:
```cpp
template < class OperatorType >
class GaussSeidelSmoother : public Solver< OperatorType >
{
public:
void solve( const OperatorType& A,
const typename OperatorType::srcType& x,
const typename OperatorType::dstType& b,
const size_t level ) override
{
if ( const auto* A_gs = dynamic_cast< const GSSmoothable< typename OperatorType::srcType >* >( &A ) )
{
A_gs->smooth_gs( x, b, level, flag_ );
}
else
{
throw std::runtime_error( "The Gauss-Seidel Operator requires the GSSmoothable interface." );
}
}
// ...
};
template < class OperatorType >
class SymmetricGaussSeidelSmoother : public Solver< OperatorType >
{
public:
void solve( const OperatorType& A,
const typename OperatorType::srcType& x,
const typename OperatorType::dstType& b,
const size_t level ) override
{
if ( const auto* A_gs = dynamic_cast< const GSSmoothable< typename OperatorType::srcType >* >( &A ) )
{
A_gs->smooth_gs( x, b, level, flag_ );
}
else
{
throw std::runtime_error( "The symmetric Gauss-Seidel Operator requires the GSSmoothable interface." );
}
if( const auto* A_gs_bw = dynamic_cast< const GSBackwardsSmoothable< typename OperatorType::srcType >* >( &A ))
{
A_gs_bw->smooth_gs_backwards( x, b, level, flag_ );
}
else
{
throw std::runtime_error( "The symmetric Gauss-Seidel Operator requires the GSBackwardsSmoothable interface." );
}
}
// ...
};
```
Thus in the example above the `GaussSeidelSmoother` would work for the `P1ConstantLaplaceOperator`, while the `SymmetricGaussSeidelSmoother` would throw an exception:
```
P1ConstantLaplaceOperator A( /* ... */ );
GaussSeidelSmoother< P1ConstantLaplaceOperator > GS ( /* ... */ );
SymmetricGaussSeidelSmoother< P1ConstantLaplaceOperator > SGS ( /* ... */ );
// works
GS.solve( A, x, b, level );
std::cout << "GS finished!" << std::endl;
// throws an exception at runtime
SGS.solve( A, x, b, level );
std::cout << "SGS finished!" << std::endl;
```Andreas WagnerAndreas Wagnerhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/101Replace Pointnd with walberla::vector2022-05-30T10:32:16+02:00Dominik Thoennesdominik.thoennes@fau.deReplace Pointnd with walberla::vectorTo reduce code duplication we could possibly replace our own pointnd implementation with walberla::vector.
1. [ ] check whether they have the same behavior
2. [ ] do refactor (could be quite some work)To reduce code duplication we could possibly replace our own pointnd implementation with walberla::vector.
1. [ ] check whether they have the same behavior
2. [ ] do refactor (could be quite some work)https://i10git.cs.fau.de/hyteg/hyteg/-/issues/176Refactor PMVectorToPLScalar and PLScalarToPMVector operators2022-03-16T16:21:31+01:00Marcus MohrRefactor PMVectorToPLScalar and PLScalarToPMVector operatorsHi,
to represent the weak forms of gradient and divergence we have the following operators
- PMVectorToPLScalarOperator
- PLScalarToPMVectorOperator
with currently $`(M, L)\in\{1,2\}\times\{1,2\}`$ and $`L\leqslant M`$. These classes a...Hi,
to represent the weak forms of gradient and divergence we have the following operators
- PMVectorToPLScalarOperator
- PLScalarToPMVectorOperator
with currently $`(M, L)\in\{1,2\}\times\{1,2\}`$ and $`L\leqslant M`$. These classes are already templated. However, this is only w.r.t. the scalar suboperators. We still have different implementations for the different function space combinations. I suggest to
- [x] convert that into a single template class
- [x] add accessor methods to the scalar suboperators (needed e.g. to call `computeAndStoreLocalElementMatrices()` on them)
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/92General interface for (numerical) form integration2022-02-22T12:19:10+01:00Nils KohlGeneral interface for (numerical) form integrationWe need to define a proper interface for a "Form" class.
This allows us to separate form integration (stencil assembly) from the actual application (or relaxation, ...) kernels.
For instance we would only need an ElementwiseOperator ins...We need to define a proper interface for a "Form" class.
This allows us to separate form integration (stencil assembly) from the actual application (or relaxation, ...) kernels.
For instance we would only need an ElementwiseOperator instead of an Elementwise- plus a Blen{}dingOperator.
Our current idea for the integration interface is as follows (or similar):
```
class SomeForm
{
// 2D P1
void integrate( const Vec3< Vec2 > in, Vec3 & out );
// 3D P1
void integrate( const Vec4< Vec3 > in, Vec4 & out );
};
```
Unclear:
* What other parameters shall the integrate form have?
~~Currently we think that the PrimitiveID as another parameter should be sufficient (the storage can be given during construction).~~ -> it is unclear which PrimitiveIDs are required here? For each point of the micro-element?
Maybe we should keep it as simple as possible.
* How do we define the integrate functions for different stiffness matrix sizes (e.g. for the "mixedoperators")?
* How do we define the evaluation point (i.e. the row that we want to compute from the stiffness matrix)?
* Better to pass constant sized arrays than custom vector data structures to be more compatible to code generators.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/125Refactor PETSc matrix assembly API2022-02-04T18:13:00+01:00Nils KohlRefactor PETSc matrix assembly APII suggest improving the `createMatrix()` interface to simplify adding new operators.
Overloading of `createMatrix()` could be one solution - the current templates are
confusing and hard to get right. This especially applies for the impl...I suggest improving the `createMatrix()` interface to simplify adding new operators.
Overloading of `createMatrix()` could be one solution - the current templates are
confusing and hard to get right. This especially applies for the implementation of
more complicated operators or wrappers such as the `UnsteadyDiffusionOperator`.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/169Boundary Conditions and Constructors of Function classes2021-12-20T15:32:56+01:00Marcus MohrBoundary Conditions and Constructors of Function classesHi,
I just noted a small inconsistency in the constructors of the `P*VectorFunction`s compared to those of the scalar functions. All of
- P1Function
- P2Function
- EdgeDoFFunction
- FaceDoFFunction
provide a constructor version that a...Hi,
I just noted a small inconsistency in the constructors of the `P*VectorFunction`s compared to those of the scalar functions. All of
- P1Function
- P2Function
- EdgeDoFFunction
- FaceDoFFunction
provide a constructor version that allows to set a `BoundaryCondition`. The constructor which does not allow this, in turn delegates to the other one using our default variant `BoundaryCondition::create0123BC()` to generate a B.C. object.
- P1VectorFunction
- P2VectorFunction
both currently provide only a single constructor that
- does not allow to set the boundary condition
- and also does not set the default
IMHO we should fix this by extending the two classes.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/153Deprecation of old forms2021-12-09T15:17:26+01:00Marcus MohrDeprecation of old formsHi,
I took the liberty to mark the following forms as deprecated, since we generated replacements for them with the new *hyteg-form-generator*:
- P1FormEpsilon.hpp
- P1FormLaplace.hpp
- P1FormMass.hpp
- P1FormPSPG.hpp
- P2FormEpsilon.h...Hi,
I took the liberty to mark the following forms as deprecated, since we generated replacements for them with the new *hyteg-form-generator*:
- P1FormEpsilon.hpp
- P1FormLaplace.hpp
- P1FormMass.hpp
- P1FormPSPG.hpp
- P2FormEpsilon.hpp
If there are no objections, I will make the corresponding operator typedefs use the new forms and delete the old source files in a not so distant commit.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/165Culling of Operators2021-10-14T15:18:31+02:00Marcus MohrCulling of OperatorsDecide which of these operators should be supported and which removed:
- P1ConstantOperator
- P1ConstantOperator_new
- P1PointwiseOperator
- P1PolynomialBlendingOperator
- P1SurrogateOperator
- P1VariableOperator
- P1VariableOperato...Decide which of these operators should be supported and which removed:
- P1ConstantOperator
- P1ConstantOperator_new
- P1PointwiseOperator
- P1PolynomialBlendingOperator
- P1SurrogateOperator
- P1VariableOperator
- P1VariableOperator_newMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/163P*ProjectNormalOperator should work a vector function instead of single scala...2021-09-30T12:50:34+02:00Nils KohlP*ProjectNormalOperator should work a vector function instead of single scalar functionsThe current implementation does not easily allow to implement the toMatrix() sparse matrix assembly method.The current implementation does not easily allow to implement the toMatrix() sparse matrix assembly method.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/142VectorFunction enhancements2021-04-01T15:54:36+02:00Marcus MohrVectorFunction enhancementsHi,
this issue is based on the comments for !381. That merge enhanced the implementation and functionality of the P1VectorFunction class. My comments were:
- Maybe we can move some of the methods (e.g. add, assign, dotLocal,...) upwar...Hi,
this issue is based on the comments for !381. That merge enhanced the implementation and functionality of the P1VectorFunction class. My comments were:
- Maybe we can move some of the methods (e.g. add, assign, dotLocal,...) upwards to a common base class instead of re-implementing basically the same stuff again in P2VectorFunction. But that is under discussion anyhow. Question is, if we get this to work nicely together with the templatisations.
- In that respect maybe also ```filter``` could be a free function?
- I definitely suggest to rename ```getMaxMagnitude()``` for VectorFunctions, as IMHO the name is very misleading. If I ask for the maximal magnitude of a velocity field e.g. I'd expect to get that back and not the maximal magnitude over all components.
Cheers
MarcusMarcus MohrMarcus Mohr