hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2020-07-31T11:23:44+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/88Fix/test SchurCG2020-07-31T11:23:44+02:00Nils KohlFix/test SchurCGMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/96Black-Box Matrix Output2020-10-07T14:04:44+02:00Nils KohlBlack-Box Matrix OutputFor debugging purposes it would be nice to have some sort of black-box matrix output (to PETSc / Matlab) for arbitrary matrices - especially if they are assembled on-the-fly or are built with inverse matrices (e.g. Schur-complement).
Th...For debugging purposes it would be nice to have some sort of black-box matrix output (to PETSc / Matlab) for arbitrary matrices - especially if they are assembled on-the-fly or are built with inverse matrices (e.g. Schur-complement).
Therefore we could repeatedly apply the matrix to unit vectors to emulate a multiplication with the identity.
The resulting vectors can then be collected and written into multiple files or (probably better) be assembled into
a PETSc data structure (and then written using the available PETSc -> Matlab functions).Daniel DrzisgaDaniel Drzisgahttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/121Dynamic function allocation on arbitrary levels and primitives2020-07-31T11:31:48+02:00Nils KohlDynamic function allocation on arbitrary levels and primitivesFor adaptive simulations we require a more flexible and dynamic mechanism to allocate function memory.
This especially involves arbitrary levels and primitives.
Potential issues:
- ~~min / maxLevel currently fixed~~
- internal functions...For adaptive simulations we require a more flexible and dynamic mechanism to allocate function memory.
This especially involves arbitrary levels and primitives.
Potential issues:
- ~~min / maxLevel currently fixed~~
- internal functions (e.g. in solvers) must be adapted as well (this depends strongly on the application)
- operators and communicators need to be adaptedAndreas WagnerAndreas Wagnerhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/129Blending PSPG inv diag operator2021-12-07T14:38:49+01:00Benjamin MannBlending PSPG inv diag operatorIn `P2P1ElementwiseBlendingStokesOperator` the constant `P1PSPGInvDiagOperator` is used.
Corresponding blending operator required?In `P2P1ElementwiseBlendingStokesOperator` the constant `P1PSPGInvDiagOperator` is used.
Corresponding blending operator required?Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/134FunctionIterator< P2Function > not working correctly2020-09-22T15:25:18+02:00Marcus MohrFunctionIterator< P2Function > not working correctlyHi,
there seems (in my understanding) to be a problem with the implementation of the ````FunctionIterator```` class, when used on a ````P2Function````. When I run this test:
````
P2Function< real_t > p2Func( "P2 test func", storage, lev...Hi,
there seems (in my understanding) to be a problem with the implementation of the ````FunctionIterator```` class, when used on a ````P2Function````. When I run this test:
````
P2Function< real_t > p2Func( "P2 test func", storage, level, level );
for ( auto val : FunctionIterator< P2Function< real_t > >( p2Func, level ) )
{
if ( !val.isEdgeDoF() && !val.isVertexDoF() )
{
WALBERLA_ABORT( "P2 DoF must be either on micro edge or micro vertex!" );
}
}
````
it aborts, see [affa19070].
Cheers
MarcusNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/164Trying to use single or mixed precision2022-05-25T14:49:26+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/171DG implementation2022-04-11T16:48:50+02:00Nils KohlDG implementation# Planned features
* Discontinuous Galerkin implementation with arbitrary choice of (polynomial) shape functions
* arbitrary order
* p-refinement over macro-elements
* matrix-free operator evaluation
* weak form generation via HFG
* eva...# Planned features
* Discontinuous Galerkin implementation with arbitrary choice of (polynomial) shape functions
* arbitrary order
* p-refinement over macro-elements
* matrix-free operator evaluation
* weak form generation via HFG
* evaluation of functions and linear functionals for right-hand side assembly generated via HFG
* direct volume to volume communication (interface primitives not used)
* SIP for Poisson
Probably also(?)
* hp-multigrid (maybe also projection into continuous element space?)
* weakly imposed boundary conditions
* upwind operator
# Roadmap
- [x] Volume DoF data structure + DGFunction class w/ basic indexing functionality
- [x] DGOperator class, apply, toMatrix()
- [x] mass form, interpolation
- [x] linear form for RHS
- [x] Laplace form (SIP, interface integrals)
- [x] communication (PackInfo etc.), macro-interface integrals
- [x] inhom. Dirichlet BCs.
- [ ] higher order shape functions
- [ ] HFG refactoring and fixed DGForm API
- [x] 3D extensions
- [ ] p-adaptivity
# Possible optimizations / open refactoring / dev notes
- [ ] optimize evaluation by precomputing and storing trafo matrices on each macro-face / macro-cell (it's recomputed every time in the evaluation function)
- [ ] make all methods in DGBasisInfo const
- [ ] give DGForms the following virtual methods
* `isConstant()`: true if the form is constant over the macro - so optimization can be applied
* `isInlined()`: true if entire kernel is available
* `onlyInnerIntegrals()`: true if only volume integrals are non-zero (think mass matrix) - this allows to implement efficient(?) local inversion of the block-diagonal system without communication
- [ ] probably we should not double the information about the local polynomial degree in each macro in the DGFunction AND VolumeDoFFunction
- [x] optimize VTK evaluation by new DGFunction::evaluate( faceID, microIdx, faceType, ... ) method that skips looking for the micro-element - we know already which one we are targeting (_this is not only an optimization but also fixes slightly incorrect visualization_)
- [ ] what to do with the DoFType 'flags'?
- [x] implement affine element-local evaluation directly in HFG
- [ ] Optimize HFG trafo matrix computations by letting it know which element vertices belong to the interface.
This should allow for some cancellations since some of the input points are actually equal.
- [ ] There is an issue if the boundary macros are marked as 'Inner' as done for Stokes usually - since then the DGOperator 'thinks' that there must be another volume macro on the other side. Boom.
- [ ] Instead of resizing the element matrices, the HFG should rather assert that the size is already correct.Nils KohlNils Kohl