hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2019-02-15T14:29:31+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/211WIP: Resolve "Implementation of meshing for spherical shell"2019-02-15T14:29:31+01:00Marcus MohrWIP: Resolve "Implementation of meshing for spherical shell"Closes #90Closes #90https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/240[WIP] mohr/integrate general forms into master2019-07-17T12:42:45+02:00Marcus Mohr[WIP] mohr/integrate general forms into masterHi,
working on issue #99. Things that need to be done:
- [x] merge general forms into master fixing merging issues
- [x] make sure compilation of framework, apps and tests works
- [x] implement parts that are missing for assembling P2 ...Hi,
working on issue #99. Things that need to be done:
- [x] merge general forms into master fixing merging issues
- [x] make sure compilation of framework, apps and tests works
- [x] implement parts that are missing for assembling P2 stencils in 3D
- [x] make sure there are no more errors in test suite
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/302WIP: Resolve "Suggestion to rename createMatrixFromFunction()"2020-01-28T21:58:35+01:00Marcus MohrWIP: Resolve "Suggestion to rename createMatrixFromFunction()"Closes #119Closes #119https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/404New VectorFunction classes and hierarchy2021-04-01T13:18:09+02:00Marcus MohrNew VectorFunction classes and hierarchyThe merge will resolve issue #142. Especially it will bring a new class hierarchy for vector-valued functions. The associated base class provides most of the methods we find in our ```P1Function``` and ```P2Function``` classes, but allow...The merge will resolve issue #142. Especially it will bring a new class hierarchy for vector-valued functions. The associated base class provides most of the methods we find in our ```P1Function``` and ```P2Function``` classes, but allow to directly operate on vector functions, which means we can e.g. write
```
f.uvw.multElementwise( { f.uvw, outwardNormal.uvw }, l );
f.uvw.assign( { rayleighNumber }, { f.uvw }, l, All );
```
instead of the previous
```
f.uvw.u.multElementwise( {f.uvw.u, outwardNormal.uvw.u}, l );
f.uvw.v.multElementwise( {f.uvw.v, outwardNormal.uvw.v}, l );
f.uvw.w.multElementwise( {f.uvw.w, outwardNormal.uvw.w}, l );
f.uvw.u.assign( {rayleighNumber}, {f.uvw.u}, l, All );
f.uvw.v.assign( {rayleighNumber}, {f.uvw.v}, l, All );
f.uvw.w.assign( {rayleighNumber}, {f.uvw.w}, l, All );
```
Access to indiviudal scalar component functions is supported, e.g. via operator[]. This allows implementing loops based on the
return value of the ```getDimension()``` method.
```
for ( uint_t k = 0; k < function.uvw.getDimension(); k++ )
{
prolongationOperator_.prolongate( function.uvw[k], sourceLevel, flag );
}
```
which is important, since we do not provide a **dummy** third component for 2D vector functions.
The implementation relies on CRTP as our scalar functions do and as we discussed for the proposed **block functions**.
There is a first draft for a ```VectorToVector``` operator. But that only provides ```apply()``` as method and is not really used, yet.
This merge will bring many changes, so please take a look at it (and approve :sweat_smile:)
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/455Make P2P1TaylorHoodFunction child of BlockFunction2021-10-14T16:37:21+02:00Marcus MohrMake P2P1TaylorHoodFunction child of BlockFunctionThe merge makes the ```P2P1TaylorHoodFunction``` and the ```P1CahnHilliardFunction``` children of ```BlockFunction```. The
```FunctionWrapper``` class is adapted, so that we can keep ```uvw``` and ```p``` as members of the ```P2P1TaylorH...The merge makes the ```P2P1TaylorHoodFunction``` and the ```P1CahnHilliardFunction``` children of ```BlockFunction```. The
```FunctionWrapper``` class is adapted, so that we can keep ```uvw``` and ```p``` as members of the ```P2P1TaylorHoodFunction```, similar for the ```P1CahnHilliardFunction```. Thus, we do not need to adapt the operators, solvers, ..., yet.
Note that we need to explicitely define a copy constructor in the children to take care of setting the entries in the ```subFuncs_``` vector inherited from the ```BlockFunction``` parent. Otherwise nasty memory errors will occur.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/545Issue #181: Modify Matrix and PointND classes2022-12-01T11:27:14+01:00Marcus MohrIssue #181: Modify Matrix and PointND classesIn light of issue #181 this commit changes the implementation details
of the Matrix and PointND classes, while leaving their API basically
unchanged.
The major switch is that both classes now use an Eigen::Matrix object
to store their d...In light of issue #181 this commit changes the implementation details
of the Matrix and PointND classes, while leaving their API basically
unchanged.
The major switch is that both classes now use an Eigen::Matrix object
to store their data instead of the previous static 1D array of type T.
This allows to delegate all the algebraic operations to the Eigen
library and makes certain operations also available for dimensions for
which so far they had not been implemented.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/560Upgrade in the plates module in assigning plates to points2023-01-24T16:13:26+01:00Berta VilacísUpgrade in the plates module in assigning plates to pointsThe function point-in-polygon that finds which plate belongs the point has been upgraded.
Now, it uses the coordinates lon, lat and places the point and the polygon at the surface of a sphere using the boost library. It also calculates ...The function point-in-polygon that finds which plate belongs the point has been upgraded.
Now, it uses the coordinates lon, lat and places the point and the polygon at the surface of a sphere using the boost library. It also calculates the distance from the point to the polygon using the functionalities of the boost library.
Each point has a unique solution to the polygon that belongs to.
Also we generalised plates, such as, internally it does the conversion from xyz to lon lat coordinate system, allowing the user to pass in any xyz point in any radius.
The dependency of plates to CGAL has been removed and such the cmake files have been modified.
(commits 1a46caad50806b576b2fb1d63f2efe8a32ab5015, 0c7ed8c551c039a006aa366355edc7edbe66d72a and 244525a91244f11250b68ead35ea1abf27696a63)https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/616Remove useVTKQuadratic[Triangle|Tetra]_ from VTKOutput class2023-06-23T09:26:00+02:00Marcus MohrRemove useVTKQuadratic[Triangle|Tetra]_ from VTKOutput classThe merge removes the two attributes and associated getter/setter methods from the VTKOutput class. They had been introduced as part of the transition to write P2Elements as such and not as P1Elements on a refined mesh, see also !594. Wi...The merge removes the two attributes and associated getter/setter methods from the VTKOutput class. They had been introduced as part of the transition to write P2Elements as such and not as P1Elements on a refined mesh, see also !594. With this we also remove support for the old approach and the associated tests.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/625Draft: Move Table and KeyValueStore to a central place2023-07-18T09:35:57+02:00Daniel BauerDraft: Move Table and KeyValueStore to a central place`Table` and `KeyValueStore` can be used to write data in HyTeG apps/tests such that they can be later directly included in LaTeX code.
See the docstrings for example usages.
This MR documents the existing classes and moves them to `src/...`Table` and `KeyValueStore` can be used to write data in HyTeG apps/tests such that they can be later directly included in LaTeX code.
See the docstrings for example usages.
This MR documents the existing classes and moves them to `src/hyteg/dataexport`.
Before, they were hidden away in `apps/2023-bauer-mt`.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/734Update/extend documentation of PrimitiveID class2024-03-28T20:35:31+01:00Marcus MohrUpdate/extend documentation of PrimitiveID classThis merge request
- re-writes and extends documentation text of `PrimitiveID` class
- adds three images to better explain the format of the bit pattern
- groups documentation of `PrimitiveID::asIntArray()` methods together
- updates met...This merge request
- re-writes and extends documentation text of `PrimitiveID` class
- adds three images to better explain the format of the bit pattern
- groups documentation of `PrimitiveID::asIntArray()` methods together
- updates meta-data in `PrimitiveID.hpp`
- relocates PrimitiveID.hpp to the sub-folder `src/hyteg/primitives`https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/732TerraNeo - parameter handling, initialization, radial profiles2024-03-28T11:08:09+01:00Nils KohlTerraNeo - parameter handling, initialization, radial profilesThis MR is a continuation of !712 (and !707 which is a subset of !712).
The MR rebases and refactors what has been implemented in !712.
Introduces:
* parameter handling for the TN app
* radial profile computation
* IO for radial profil...This MR is a continuation of !712 (and !707 which is a subset of !712).
The MR rebases and refactors what has been implemented in !712.
Introduces:
* parameter handling for the TN app
* radial profile computation
* IO for radial profiles
* temperature initialization functions
Major edits compared to !712:
* refactored temperature initialization functions (now just a "library" of functions that create lambdas for `interpolate()`)
* refactored the radial profile tool (much more efficient as all relevant values are computed in a single loop, [free your functions](https://github.com/CppCon/CppCon2017/blob/master/Presentations/Free%20Your%20Functions/Free%20Your%20Functions%20-%20Klaus%20Iglberger%20-%20CppCon%202017.pdf))
* refactored parameter IO (using json with better error handling, no more global variables, etc.)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/716GEMV2024-03-21T21:55:14+01:00Nils KohlGEMVThis MR implements the `gemv` as described in detail in #253.
It turns out that only minor changes have to applied to the `apply()` method to make this work (at least for the elementwise operators).This MR implements the `gemv` as described in detail in #253.
It turns out that only minor changes have to applied to the `apply()` method to make this work (at least for the elementwise operators).Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/708Rename PETScLUSolver::reassembleMatrix() to setReassembleMatrix()2024-02-23T10:15:40+01:00Marcus MohrRename PETScLUSolver::reassembleMatrix() to setReassembleMatrix()Rationale: It is a setter method and after the change naming is consistent with `EigenSparseDirectSolver::setReassembleMatrix()`Rationale: It is a setter method and after the change naming is consistent with `EigenSparseDirectSolver::setReassembleMatrix()`https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/638Remove isDummy_ attribute from Function class2023-07-31T23:48:07+02:00Marcus MohrRemove isDummy_ attribute from Function classResolves issue #225Resolves issue #225Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/630Change FEFunctionWriter to use CRTP2023-07-19T17:14:08+02:00Marcus MohrChange FEFunctionWriter to use CRTPThe previous inheritance concept, with FEFunctionWriter as base class for the concrete (AdiosWriter and VTKOutput) child classes was faulty. The
problem was that the add() method is templated and templated methods are currently not allow...The previous inheritance concept, with FEFunctionWriter as base class for the concrete (AdiosWriter and VTKOutput) child classes was faulty. The
problem was that the add() method is templated and templated methods are currently not allowed to be virtual, too.
So with this commit we change to CRTP. Not sure how much sense this makes, but it will at least enforce a minimal level of consistency in the methods offered by the "child" classes.Extend capabilities for exporting data by adding support for ADIOS2Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/628Move Table and KeyValueStore to a central place2023-07-20T11:23:12+02:00Daniel BauerMove Table and KeyValueStore to a central placeRebase of !625.
`Table` and `KeyValueStore` can be used to write data in HyTeG apps/tests such that they can be later directly included in LaTeX code. See the docstrings for example usages.
This MR documents the existing classes and mo...Rebase of !625.
`Table` and `KeyValueStore` can be used to write data in HyTeG apps/tests such that they can be later directly included in LaTeX code. See the docstrings for example usages.
This MR documents the existing classes and moves them to `src/hyteg/dataexport`. Before, they were hidden away in `apps/2023-bauer-mt`.Daniel BauerDaniel Bauerhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/624Make HyTeG aware of system's byte order2023-07-12T13:17:33+02:00Marcus MohrMake HyTeG aware of system's byte orderMerge adds a new macro `HYTEG_ARCH_ENDIANESS` to HytegDefinitions that is set by CMake to the value of `CMAKE_CXX_BYTE_ORDER`. We also add a query method `systemEndianess()` to BuildInfo. We use this information then to place the correct...Merge adds a new macro `HYTEG_ARCH_ENDIANESS` to HytegDefinitions that is set by CMake to the value of `CMAKE_CXX_BYTE_ORDER`. We also add a query method `systemEndianess()` to BuildInfo. We use this information then to place the correct information into our VTU output files, instead of hardcoding LittleEndian everywhere.
In order to use the CMake macro we need 3.20 as minimal version and document this in our README.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/622Resolve other aspect of issue 2022023-06-29T08:21:05+02:00Marcus MohrResolve other aspect of issue 202After this MR the FunctionPropertiesTest works for the P0FunctionTag case. This demonstrates that we can use our usual machinery now to query the number of DoFs of a ```P0Function```. This resolves #202.
Additionally extension of ```num...After this MR the FunctionPropertiesTest works for the P0FunctionTag case. This demonstrates that we can use our usual machinery now to query the number of DoFs of a ```P0Function```. This resolves #202.
Additionally extension of ```numberOfInnerDoFs()``` and ```numberOfLocalDoFs()``` should be more straightforward now, as we no longer need to implement a separate template specialisation.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/619Refactor VTKOutput2023-06-27T13:41:44+02:00Marcus MohrRefactor VTKOutputIn order to prepare for different output formats and libraries this MR refactors the implementation of the existing `VTKOutput` class and also adapts structure of source file placement.In order to prepare for different output formats and libraries this MR refactors the implementation of the existing `VTKOutput` class and also adapts structure of source file placement.Extend capabilities for exporting data by adding support for ADIOS2Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/599Handle edge orientations systematically by basis transformations2023-05-31T18:06:26+02:00Daniel BauerHandle edge orientations systematically by basis transformationsThe rationale behind this MR is detailed in https://i10git.cs.fau.de/terraneo/hhg_doku/-/blob/master/P3Function_thoughts/orientations.tex.
This MR implements the proposed approach for the N1E1 space.
# TL;DR
I spent some time thinking a...The rationale behind this MR is detailed in https://i10git.cs.fau.de/terraneo/hhg_doku/-/blob/master/P3Function_thoughts/orientations.tex.
This MR implements the proposed approach for the N1E1 space.
# TL;DR
I spent some time thinking about how to handle orientation of mesh entities and how to implement that in HyTeG having the general case in mind.
The conclusion is that we should perform basis transformations during communication.
More details about these transforms are given in [1].
As a result only two parts in HyTeG require care: the communication (PackInfo) and the matrix assembly.
The goal is to have both generated automatically.
# Some Notes
- N1E1 forms do not depend on edge directions any more. The reason why this was introduced initially was confusion on my side about the difference between matrix diagonals and linear forms.
- Assembly of linear forms is now a free function (for N1E1) and the Operator is not defined for linear forms anymore. I am open to discussions about this.
# Related
https://i10git.cs.fau.de/terraneo/hyteg-form-generator/-/merge_requests/30
[1] M. W. Scroggs, J. S. Dokken, C. N. Richardson, and G. N. Wells, “Construction of Arbitrary Order Finite Element Degree-of-Freedom Maps on Polygonal and Polyhedral Cell Meshes,” ACM Trans. Math. Softw., vol. 48, no. 2, pp. 1–23, Jun. 2022, doi: [10.1145/3524456](https://doi.org/10.1145/3524456).Daniel BauerDaniel Bauer