hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2024-02-22T20:06:38+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/707Draft: Adding tool for temperature initialisation2024-02-22T20:06:38+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/705Add Stokes benchmarks for annulus and thick spherical shell settings2024-02-22T13:47:51+01:00Marcus MohrAdd Stokes benchmarks for annulus and thick spherical shell settingsThe benchmarks are based on and extend, w.r.t. boundary conditions, those described in [Analytical solutions for mantle flow in cylindrical and spherical shells](https://doi.org/10.5194/gmd-14-1899-2021) by Kramer et al.
Also noteworthy...The benchmarks are based on and extend, w.r.t. boundary conditions, those described in [Analytical solutions for mantle flow in cylindrical and spherical shells](https://doi.org/10.5194/gmd-14-1899-2021) by Kramer et al.
Also noteworthy is the addition of a `PythonCallingWrapper` class.https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/676Add continues outputting to LaTeX Table printer2024-01-19T17:58:21+01:00Michael ZikeliAdd continues outputting to LaTeX Table printerThe header `LaTeX/Table.hpp` provides the possibility to log rows of a tabulated `.dat` file that can later be used to, e.g. print graphs with pgfplots or also just tables in LaTeX.
This MR introduces a `writeUpdate` Method, that allows...The header `LaTeX/Table.hpp` provides the possibility to log rows of a tabulated `.dat` file that can later be used to, e.g. print graphs with pgfplots or also just tables in LaTeX.
This MR introduces a `writeUpdate` Method, that allows for intermediate printing of the tables rows, that have not been printed yet, instead of printing the entire table all the time.Michael ZikeliMichael Zikelihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/671Enable float16 support for the P1 functionspace2024-02-13T18:29:24+01:00Michael ZikeliEnable float16 support for the P1 functionspaceHyTeG was not able to work with float16 types. This merge request fixes this by adding the missing functionality for the P1 functionspace.
Necessary changes:
- [x] Template and explicit instantiate the following kernels that have been ...HyTeG was not able to work with float16 types. This merge request fixes this by adding the missing functionality for the P1 functionspace.
Necessary changes:
- [x] Template and explicit instantiate the following kernels that have been generated at some point <add, apply, assign, communicate>. The other two kernel types <GS and SOR> have not been templated yet, since they are not used for the generated operators.
- [x] Set standard to C++23 if half precision support is enabled, otherwise some basic asserts like `is_floating_point` will fail.
- [x] Add test that check if all necessary functionality of float16 is working properly.
- [x] Update walberla to support float16 support.
- [x] Make sure that `WALBERLA_BUILD_WITH_HALF_PRECISION_SUPPORT` is enabled in the pipeline.
- [x] Make sure that the remote on the submodule walberla is the walberla repo and not a local fork.
- [x] Test the implementation and float16SupportTest for older compilers as well.
- [x] Some of the now templated kernels use copy by value, while reference is sufficient. Go back and add references.
- [x] Update the license in the modified files.
---
This merge request is dependent on the walberla merge request [!643](https://i10git.cs.fau.de/walberla/walberla/-/merge_requests/643).Michael ZikeliMichael Zikelihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/659Eigen sparse solver wrapper2024-02-12T18:33:32+01:00Nils KohlEigen sparse solver wrapperTo be introduced after !658.To be introduced after !658.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/658Eigen sparse matrix and vector assembly (proxies and helper) from HyTeG's FE ...2023-11-09T10:07:10+01:00Nils KohlEigen sparse matrix and vector assembly (proxies and helper) from HyTeG's FE operators functions.See #233
Solver wrappers still left to be implemented.See #233
Solver wrappers still left to be implemented.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/657Include multiple-precision floating-point library MPFR to HyTeG2023-11-06T12:38:45+01:00Michael ZikeliInclude multiple-precision floating-point library MPFR to HyTeGMPFR is a C library for simulating arbitrary whole number precision for floating-point variables, hence enabling multiple-precision floating-point computations with correct rounding. The precision requested by the user is the number of b...MPFR is a C library for simulating arbitrary whole number precision for floating-point variables, hence enabling multiple-precision floating-point computations with correct rounding. The precision requested by the user is the number of bits used to represent the mantissa.
For more information about MPFR compare: [mpfr.org](http://www.mpfr.org/)
For better usage in HyTeG, two external C++ wrapper libraries are included as well to enable e.g. operator overloading, automatic memory management, ...
One of these is using compile time definition of the variable precision. Compare the distributor website: [mpfr::real<>](http://chschneider.eu/programming/mpfr_real/)
The other one uses a runtime definition of the variable precision. Compare the distributor website: [mpfr::mpreal](http://www.holoborodko.com/pavel/mpfr/)Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/653Particles2023-10-19T12:20:24+02:00Nils KohlParticlesThis MR implements unresolved particles via the MESA-PD particle code generation framework.
The objective is the implementation of **fluid (<)-> particle** and later **particle <-> particle** interactions. Since the particles are assume...This MR implements unresolved particles via the MESA-PD particle code generation framework.
The objective is the implementation of **fluid (<)-> particle** and later **particle <-> particle** interactions. Since the particles are assumed to be smaller than the elements, the module is referred to as _unresolved particles_. Thus fluid-particle interactions are not meant to be fully resolved but are modeled instead. At this point, only the one-way coupling (fluid acts on particles, not vice versa) is considered.
This is sufficient to, e.g., implement tracer particles.
Some notes:
* The implementation is already fully parallelized.
* There is a new tutorial (no. 12) including some images.
* The particle properties are subject to change and probably need to be discussed in the future. As of now, it is possible to flexibly add custom real and integer scalars to particles if needed.
* Direct application of velocity and force fields is possible. For tracer particles, the former is sufficient and can be interpreted as a extremely simplified form of Faxén's law (https://en.wikipedia.org/wiki/Fax%C3%A9n%27s_law). Force fields are also already supported, and naturally involve the particle mass for the computation of the resulting translational velocity.
* Theoretically, all features that are available in MESA-PD can be used. This includes, for instance, other integrators. However, using them involves generating the corresponding C++ code via MESA-PD through the python script in the `data/codegen/unresolved_particles/` directory.
* I had in mind that there has been a temporary(?) tracer particle implementation in the TerraNeo module. I cannot find it right now (could be on a branch) - and I might be wrong. If there is one, we should consider replacing it (and add required features to this new version - if possible).
* Blended domains are not yet supported.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/649Draft: To GeometryMap add a method to compute second derivatives2024-02-21T17:12:59+01:00Marcus MohrDraft: To GeometryMap add a method to compute second derivativesMain purpose of this MR is to add to our geometry maps the functionality to compute second derivaties as is e.g. needed for SUPG stabilisiation.Main purpose of this MR is to add to our geometry maps the functionality to compute second derivaties as is e.g. needed for SUPG stabilisiation.Andreas BurkhartAndreas Burkharthttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/642First version of parallel PrimitiveStorage setup from file.2023-10-23T13:54:07+02:00Nils KohlFirst version of parallel PrimitiveStorage setup from file.This MR realizes a two-step process. First, in a serial (offline) run, the SetupPrimitiveStorage is built and passed to a load balancer, followed by serialization to a file. During the actual, parallel run, the file is read via MPIIO suc...This MR realizes a two-step process. First, in a serial (offline) run, the SetupPrimitiveStorage is built and passed to a load balancer, followed by serialization to a file. During the actual, parallel run, the file is read via MPIIO such that only the portion that is necessary has to be viewed by the respective process. From that binary string, the entire PrimitiveStorage is created in parallel.
There are numerous possible optimizations - most notably, it is not clear to me right now if the current approach of simply writing all neighbor primitives to file is preferable, or if alternatively, such data should be communicated after only reading the locally allocated primitives. Maybe it does not even make a difference at all. Also, this implementation has not been tested with large setups yet.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/635Enhance functionality of FEFunctionRegistry and FunctionMultiStore2023-07-28T14:21:17+02:00Marcus MohrEnhance functionality of FEFunctionRegistry and FunctionMultiStoreThe `FEFunctionRegistry` and `FunctionMultiStore` classes are extended to
- allow to remove functions again; note: this technically touches on issues #172 and #186
- only store functions once, where uniqueness is based on the function's...The `FEFunctionRegistry` and `FunctionMultiStore` classes are extended to
- allow to remove functions again; note: this technically touches on issues #172 and #186
- only store functions once, where uniqueness is based on the function's name
This MR supersedes !634.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/634Allow to remove functions from an FEFunctionRegistry or FunctionMultiStore ob...2023-07-27T17:22:53+02:00Marcus MohrAllow to remove functions from an FEFunctionRegistry or FunctionMultiStore objectThe implementation of this feature touches on issues #172 and #186.The implementation of this feature touches on issues #172 and #186.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/632Draft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise ...2024-02-21T17:05:49+01:00Andreas BurkhartDraft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise DoFValueOperators (+Tests), Second derivatives for the Blending Maps, PETScHDF5 Function Saving, Projection subclasses for Smoothers and Restriction/Prolongation**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content o...**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content of the various diffs:
**composites/P2P1TaylorHoodCompStokesOperator.hpp:** Implements a P2P1 Block Operator for the compressible Stokes (both ALA and TALA are available) with potentially temperature dependent viscosity. It can also generate an appropriate right hand side. You can also activate or deactivate the frozen velocity approach (i.e. if the compressible term in the mass conservation equation is made explicit).
LHS velocity:
$$2 \int_{\Omega} \eta(x,T) \sigma(u) : \sigma(v) \text{ } dx - \frac{2}{\text{dim}} \int_{\Omega}{\eta(x,T) (\nabla \cdot u) \cdot (\nabla \cdot v)} \text{ } dx - \int_{\Omega} \text{div}(v)p_d \text{ } dx - \int_\Omega \frac{\text{Di}}{\Gamma_0} \rho(x) (K_T)^{-1} p_d g \cdot v \text{ } dx$$
RHS velocity:
$$-\int_\Omega \frac{\text{Ra}}{\text{Pe}} \rho(x) \alpha T_d g \cdot v \text{ } dx$$
LHS pressure (here without frozen velocity):
$$ -\int_\Omega \left (\frac{\nabla \rho(x)}{\rho(x)} \cdot u \right ) q \text{ } dx - \int_\Omega (\nabla \cdot u) q \text{ } dx$$
RHS pressure: 0
**src/p2functionspace/P2CompTransportOperator.hpp:** Implements a P2 Operator for the time (in-)dependent energy conservation equation with optional SUPG Stabilisation. Various time stepping schemes (implicit Euler, BDF2, Crank-Nicolson) are available (some additional function calls from outside might be required, e.g. the operator provides a method to save the previous time step right hand side for crank nicolson). Can also be used for the diffusion solve step when using the MMOC operator splitting approach. It can also generate an appropriate right hand side.
LHS temperature (here for the adiabatic heat on the lhs, but can be also be made explicit):
$$ \int_\Omega \frac{\partial T}{\partial t} w \text{ } dx + \int_\Omega (u \cdot \nabla T) w \text{ } dx + \int_\Omega \frac{k }{\text{Pe} \text{ } C_p}\nabla T \cdot \nabla \left ( \frac{w}{\rho(x)} \right ) \text{ } dx - \int_\Omega \text{Di} \text{ } \frac{\alpha}{C_p} T (u \cdot g )w \text{ } dx + \text{SUPG Terms (if used)}$$
RHS temperature:
$$ - \int_\Omega \frac{1}{C_p} H w \text{ } dx -\int_\Omega \frac{\text{Pe}}{\rho(x) C_p}\frac{\text{Di}}{\text{Ra}} \left (\tau\left (u,\eta\left (x,T \right )\right ) : {\varepsilon(u)}\right ) w \text{ } dx + \text{SUPG Terms (if used)}$$
The lhs and rhs above are consequently also dependent on the chosen time discretisation.
**src/hyteg/p2functionspace/P2FullViscousTDependentOperator.hpp, src/hyteg/p2functionspace/P2GradRhoRho_P2_Operator.hpp, src/hyteg/p2functionspace/P2ScaledMassDiffusionOperator.hpp, src/hyteg/p2functionspace/P2VariableBlendingKMassScalarToVectorOperator.hpp, src/hyteg/gridtransferoperators/P2toP1GradRhoRho_P2_Operator.hpp, src/hyteg/gridtransferoperators/P1toP2VariableBlendingKMassScalarToVectorOperator.hpp:** Various operators that conveniently combine the usage of multiple other operators (e.g. if we apply one on every component).
**src/elementwiseoperators:** Added all combinations of P1/P2 ElementwiseDoFValueOperator classes. These operators can be inherited from and provide a way (via the DoFValues_ vector) to access the DoFs of another FEM function during the evaluation of a form. This allows us for the creation of operators like an advection operator that takes a velocity field as an additional input.
Added a setConstantScaling function to all elementwise operators. This can be used to scale your operators by a constant on the fly (without having to create for example a linear combination form).
There are some bug fixes and the ability to use a custom form for P2ToP1 and P1ToP2 elementwise operators included.
**src/elementwiseoperators/generated:** Folder containing all of the generated ElementwiseDoFValueOperators. In particular it adds operators for adiabatic heating, advection, diffusion (only supg), temperature dep. stokes, the grad(rho)/rho * u compressible term in the mass conservation equation, div_k_grad scaled by rho^-1, mass(only supg), shear heat and respective SUPG Stabilisation terms.
**src/p1functionspace/VertexDoFFunction, src/edgedofspace/EdgeDoFFunction, src/functions/DoFValueFunctions:** Added a DoFValueFunction class that both VertexDoFFunction and EdgeDoFFunction inherit from. No previous functionality of VertexDoFFunction and EdgeDoFFunction was changed, I just implemented the additional functions defined in the DoFValueFunction base class. The defined functions are required for the DoFValueOperators to work.
**src/hyteg/composites/VelocityOperator_T_Wrapper, src/hyteg/solvers/SubstituteSolver.hpp:** Some convenient wrappers, allowing you to wrap a operator with a different VelocityOperator_T type and to use a solver for a different operator type (e.g. if you want to solve Laplace as a preconditioner, but the preconditioner is expected to be a solver for a different operator).
**src/petsc/PETScHDF5FunctionSave.hpp:** Functions that allow you to save functions and paramters via creating a PETSc Vector and saving it in parallel to a binary file via HDF5. Has some limitations since you can only reload your functions in the same configuration as you saved it.
**src/solvers/preconditioners/stokes:** Two preconditioner classes used for benchmarks and the convection model
**src/solvers/solvertemplates/StokesSolverTemplates.hpp:** Pulled over some changes to the StokesSolverTemplates solver used in the other Terraneo branches. No functionality is changed but you can now distinguish between absolute and relative tolerance.
**src/solvers/ChebyshevSmoother.hpp:** Added a subclass of the Chebyshev Smoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/solvers/GMRESSolver.hpp:** Serveral bug fixes and additional functions from Andreas Wagner to the GMRES solver which we found during our testing of the GMRES.
**src/solvers/MinResSolver.hpp:** Pulled over some changes to the MinRes solver used in the other Terraneo branches. No functionality is changed but you can now define an absolute tolerance.
**src/solvers/UzawaSmoother.hpp, /src/hyteg/composites/P2P1UzawaDampingFactorEstimationOperator.hpp:** Added functions for the estimation of the Uzawa Omega paramter also in case of the P2CompStokesOperator and added a subclass of the UzawaSmoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesProlongation.hpp, src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesRestriction.hpp:** Restriction and Prolongation operator subclasses that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**data/meshes:** Just some additional meshes which are offset from the origin (are used for testing with the sphericalCoordinateMap blending map.
**src/forms:** Just some additional generated blending forms.
**src/geometry:** Added second derivative functions (needed for SUPG Stabilisiation) for all blending maps and a new spherical coordinate map.
**tests/hyteg/operators:** Added tests checking if the various DoFValueOperators are calculating the correct integrals and if the diagonal calculation for the temperature dependent stokes works.
Hopefully I haven't forgotten anything and these are all changes.Andreas BurkhartAndreas Burkharthttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/627Add capability to export FE functions for visualisation using the ADIOS2 library2023-07-17T14:34:59+02:00Marcus MohrAdd capability to export FE functions for visualisation using the ADIOS2 libraryThis MR extends the dataexport capabilities of HyTeG by allowing to use the [ADIOS 2: The Adaptable Input Output (I/O) System version 2](https://csmd.ornl.gov/software/adios2) to write FE function data to file for visualisation with Para...This MR extends the dataexport capabilities of HyTeG by allowing to use the [ADIOS 2: The Adaptable Input Output (I/O) System version 2](https://csmd.ornl.gov/software/adios2) to write FE function data to file for visualisation with ParaView.
The corrent implementation so far only supports functions of type
- P1Function + P1VectorFunction
- P2Function + P2VectorFunction
- P2P1TaylorHoodFunction
but is easily extensible by adding another specialised sub-writer class.Extend capabilities for exporting data by adding support for ADIOS2Marcus MohrMarcus Mohrhttps://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 Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/600Allow asking a Primitive for its type2023-05-19T17:19:54+02:00Marcus MohrAllow asking a Primitive for its typeIn most of our current algorithms we (implicitely) know what type of primitive we are dealing with, i.e. whether we are working on a `Cell`, `Face`, `Edge` or `Vertex`. This largely results from the fact that we ask a `PrimitiveStorage` ...In most of our current algorithms we (implicitely) know what type of primitive we are dealing with, i.e. whether we are working on a `Cell`, `Face`, `Edge` or `Vertex`. This largely results from the fact that we ask a `PrimitiveStorage` object to provide us with all local primitives of a certain type, e.g. via `PrimitiveStorage::getFaces()`.
Still to me it feels strange that we can neither query an object of type `Primitive` to obtain its type, nor that this is encoded in its associated `PrimitiveID`. There are some situations, where we might not (implicitely) know what kind of primitive we are dealing with. An example at the moment would be the migration of primitives between MPI processes. As a consequence of this the `PrimitiveStorage` class defines its own `PrimitiveTypeEnum` and provides a `getPrimitiveType()` method, which, presented with a `PrimitiveID` will return the type of the primitive, if this is either present locally, or in the immediate neighbourhood. If not, it will return `INVALID`.
The idea of this MR is to equip the `Primitive` class itself with a `PrimitiveTypeEnum` type that only has the values `CELL`, `FACE`, `EDGE` and `VERTEX` and a pure virtual function `Primitive::getType()` that can be used to query this. The latter is then easily implemented in the child classes.
The MR preserves `PrimitiveStorage::PrimitiveTypeEnum`, because I did not want to add a special situation `INVALID` enum to `Primitive::PrimitiveTypeEnum`. The former quasi extends the latter, based on fixed int values, so that we can cast the former into the latter.
That feels not ideal, but I am too unfamiliar with the details of primitive migration to understand, why we might want to send a nullptr together with an `INVALID` from one process to another, to change that.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/597Add function for writing blended coarse mesh2023-05-12T10:04:52+02:00Daniel BauerAdd function for writing blended coarse meshWith this MR we can visualize meshes on the physical domain.
![image](/uploads/2412529a9f21b3c4d7b2c3d6cacd1f7a/image.png)
Edit: Now, VTP and poly lines are used.With this MR we can visualize meshes on the physical domain.
![image](/uploads/2412529a9f21b3c4d7b2c3d6cacd1f7a/image.png)
Edit: Now, VTP and poly lines are used.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/594Allow use of isoparametric elements in VTKOutput for P2Functions2023-06-22T17:38:46+02:00Marcus MohrAllow use of isoparametric elements in VTKOutput for P2FunctionsThe merge introduces a change to the functionality of the `VTKOutput` class. When writing `P2(Vector)Function`s the default now is to use *VTK_QUADRATIC_TRIANGLE* or *VTK_QUADRATIC_TETRA* as cell type.
The old way to export these functi...The merge introduces a change to the functionality of the `VTKOutput` class. When writing `P2(Vector)Function`s the default now is to use *VTK_QUADRATIC_TRIANGLE* or *VTK_QUADRATIC_TETRA* as cell type.
The old way to export these functions as `P1Function`s on a refined mesh is for the moment still supported and can be activated by calling
- `setUseVTKQuadraticTriangle( false )` or
- `setUseVTKQuadraticTetra( false )`
on the corresponding `VTKOutput` object.
Comparison of the old versus the new approach looks good so far. In the following figures the left part shows a visualisation with the old and the right with the new approach:
![VTK_Quadratic_Triangle-partialAnnulus](/uploads/7fc7c7ed185be1f2fd4bd6ab77057d21/VTK_Quadratic_Triangle-partialAnnulus.png)
![VTK_QUADRATIC_TETRA_3TETS_LVL2-v2](/uploads/3a5ce647b6dca79acc120c590bca1df5/VTK_QUADRATIC_TETRA_3TETS_LVL2-v2.png)Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/585Add isIdentity and isAffine to GeometryMap2023-04-20T17:38:29+02:00Daniel BauerAdd isIdentity and isAffine to GeometryMapFixes hyteg/hyteg#208.Fixes hyteg/hyteg#208.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/584Enriched Galerkin functionspace2023-04-19T19:31:44+02:00Fabian BöhmEnriched Galerkin functionspaceAdds the Enriched Galerkin discretization to HyTeG, contained in directory src/hyteg/egfunctionspace:
- Forms for mass, div, divt, Laplacian and epsilon
- corresponding operators with and without Nitsche-type boundary conditions (Nits...Adds the Enriched Galerkin discretization to HyTeG, contained in directory src/hyteg/egfunctionspace:
- Forms for mass, div, divt, Laplacian and epsilon
- corresponding operators with and without Nitsche-type boundary conditions (Nitsche-operators are preferred due to their symmetry)
- a Stokes-function and operators in directory src/hyteg/composites
- interpolation operators between DG and CG of first degree with P1toDGOperator in directory src/hyteg/dgfunctionspace
- additional addVolumeGhostlayer functionality in vertexDoFFunction required in P1toP0Operator and P0toP1Operator
Two benchmarks with strongy varying viscosity from literature reside in apps/2022-eg-varvisc.
tests/hyteg/egfunctionspace contains tests for operator symmetry, forms, matvec/apply, basic operations of EGFunction and convergence tests.