hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2023-11-09T10:09:19+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/233Sparse matrix wrapper for Eigen2023-11-09T10:09:19+01:00Nils KohlSparse matrix wrapper for EigenSince we ship Eigen anyway, it would be great if we had a sparse matrix wrapper for their linear solvers (thanks @he66coqe for suggesting this!). This would also yield access to sparse _direct_ solvers without the need to install PETSc. ...Since we ship Eigen anyway, it would be great if we had a sparse matrix wrapper for their linear solvers (thanks @he66coqe for suggesting this!). This would also yield access to sparse _direct_ solvers without the need to install PETSc. Clearly, the Eigen implementations are not well-suited for (massively) parallel computations.https://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/184Make evaluate() method of FE Function Classes Blending-Aware2023-05-26T16:53:56+02:00Marcus MohrMake evaluate() method of FE Function Classes Blending-AwareHi,
as recently discussed on [MatterMost](https://i10chat.cs.fau.de/lssall/pl/r1oucstaupdr7kucfpqf6144wr) the current implementation of the `evaluate()` methods of our FE function classes is implicitly assuming that the point coordinate...Hi,
as recently discussed on [MatterMost](https://i10chat.cs.fau.de/lssall/pl/r1oucstaupdr7kucfpqf6144wr) the current implementation of the `evaluate()` methods of our FE function classes is implicitly assuming that the point coordinates it receives are w.r.t. to the computational domain. If the coordinates are "blended", i.e. w.r.t. the physical domain, we will either get incorrect values for the point, or none at all, since no enclosing primitive will be found.
The outcome of our discussion IMHO is that we want to change this behaviour. Technically the requirement that the blending function must be globally a homeomorphism allows us to map the coordinates from the physical domain back to the computational domain, using a primitive's local blending map, and then check, whether the mapped point belongs to the primitive in the computational domain.
Note that this change will, of course, affect existing code that passes points with coordinates in the computational domain, such as in the current [MMOC implementation](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/src/coupling_hyteg_convection_particles/MMOCTransport.hpp#L384).
As an aside I suggest to also remove in the process the specialisation of `evaluate()` for `real_t` using `constexpr if`, to get cleaner code.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/206Evaluate seems broken2023-04-05T14:59:26+02:00Andreas BurkhartEvaluate seems brokenI wanted to test some implementation against evaluate in terms of speed and noticed some strange behaviour of P1Function::evaluate and P2Function::evaluate. If you want to evaluate at one of the DoFs evaluate seems to return 0 everywhere...I wanted to test some implementation against evaluate in terms of speed and noticed some strange behaviour of P1Function::evaluate and P2Function::evaluate. If you want to evaluate at one of the DoFs evaluate seems to return 0 everywhere in case of a P1 Function and 0 at specific DoFs in case of a P2 Function.
I've created a branch called _"burk/evaluate"_ with a minimal example in _"tests/hyteg/evaluateTest.cpp"_.
In this example I interpolate a function with evaluations of another function (in this case a function which is 1 everywhere).
This is the result in case of a P2 Function: DoFs where evaluate gives 0 (without indicating that it could not find an associated element by returning false) which seem to follow a pattern.
![evaluate](/uploads/99a7c904addce039f7ad042b837fe5a5/evaluate.png)
This certainly is not a pressing issue as we don't want to use evaluate anyway if it can be helped, but I thought to document the issue at least.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/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/166License file2021-11-24T08:17:53+01:00Marcus MohrLicense fileHi,
shouldn't the ```LICENSE``` file in the project root contain some text :smiley: ? I mean we have the GPL info in the source/header files, but still ...
Cheers
MarcusHi,
shouldn't the ```LICENSE``` file in the project root contain some text :smiley: ? I mean we have the GPL info in the source/header files, but still ...
Cheers
MarcusDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/151Add interpolate() method to CSFVectorClass that supports BoundaryUID2021-05-15T19:01:05+02:00Marcus MohrAdd interpolate() method to CSFVectorClass that supports BoundaryUIDIt would be convenient, if the CSFVectorClass was to provide an ```interpolate()``` method that allows passing a BoundaryUID. This should be straightforward as the **P[12]Function** classes and the underlying **[Vertex|Edge]DoFFunction**...It would be convenient, if the CSFVectorClass was to provide an ```interpolate()``` method that allows passing a BoundaryUID. This should be straightforward as the **P[12]Function** classes and the underlying **[Vertex|Edge]DoFFunction** classes already support that.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/137Is PetscScalar the correct type for us?2020-10-07T12:24:31+02:00Marcus MohrIs PetscScalar the correct type for us?Hi,
I wanted to do some test runs with HyTeG on the LRZ Linux cluster. For this I wanted to build with HYTEG_BUILD_WITH_PETSC=yes. It turns out that this fails. I get the following errors
```
[ 0%] Building CXX object src/hyteg/CMakeFi...Hi,
I wanted to do some test runs with HyTeG on the LRZ Linux cluster. For this I wanted to build with HYTEG_BUILD_WITH_PETSC=yes. It turns out that this fails. I get the following errors
```
[ 0%] Building CXX object src/hyteg/CMakeFiles/hyteg.dir/edgedofspace/EdgeDoFProjectNormalOperator.cpp.o
/dss/dsshome1/lxc07/uk502aj/HyTeG/HyTeG/src/hyteg/FunctionMemory.hpp(48): error: static assertion failed with "Wrong ValueType template"
static_assert( std::is_arithmetic< ValueType >::value, "Wrong ValueType template" );
^
detected during:
instantiation of class "hyteg::FunctionMemory<ValueType> [with ValueType=PetscScalar]" at line 587 of "/dss/dsshome1/lxc07/uk502aj/HyTeG/HyTeG/src/hyteg/edgedofspace/EdgeDoFMacroEdge.hpp"
instantiation of "void hyteg::edgedof::macroedge::createVectorFromFunction(const walberla::uint_t={size_t={unsigned long}} &, hyteg::Edge &, const hyteg::PrimitiveDataID<hyteg::FunctionMemory<ValueType>, hyteg::Edge> &, const hyteg::PrimitiveDataID<hyteg::FunctionMemory<int>, hyteg::Edge> &, const std::shared_ptr<hyteg::VectorProxy> &) [with ValueType=PetscScalar]" at line 51 of "/dss/dsshome1/lxc07/uk502aj/HyTeG/HyTeG/src/hyteg/edgedofspace/EdgeDoFPetsc.hpp"
/dss/dsshome1/lxc07/uk502aj/HyTeG/HyTeG/src/hyteg/edgedofspace/EdgeDoFMacroEdge.hpp(593): error: no suitable conversion function from "PetscScalar" to "walberla::real_t={double}" exists
vec->setValue( numerator[idx], src[idx] );
```
A closer inspection shows that the reason seems to be that the PETSc installation on the cluster makes ```PetscScalar``` a ***complex value***. Output of
````
#include <type_traits>
#include <iostream>
#include <petscsys.h>
int main( void ) {
PetscScalar x = 4.0;
std::cout << "Value of x is " << x << std::endl;
std::cout << "std::is_arithmetic< PetscScalar > gives " << std::is_arithmetic< PetscScalar >::value << std::endl;
}
````
is
````
Value of x is (4,0)
std::is_arithmetic< PetscScalar > gives 0
````
This behaviour seems to be okay from the PETSc side as the [documentation](https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscScalar.html) leaves open whether it will be a real- or complex-valued scalar.
Maybe ```PetscReal``` is the datatype we actually want to use?
Cheers
MarcusNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/111Flexible implementation of boundary handling for additive communication2020-02-24T16:01:01+01:00Nils KohlFlexible implementation of boundary handling for additive communicationDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/42Automatic mesh generation for simple domains2019-05-23T16:44:18+02:00Nils KohlAutomatic mesh generation for simple domainsSince we mainly target simulations on certain geometries for TN, we should implement in-library mesh generation for those (e.g. box and annulus).
The user then does not need external software to test these geometries.Since we mainly target simulations on certain geometries for TN, we should implement in-library mesh generation for those (e.g. box and annulus).
The user then does not need external software to test these geometries.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/49Modularization2019-02-18T17:34:10+01:00Nils KohlModularizationWe want to modularize our framework to speed up compilation and to get a better code structure.
Current proposal (modules are ***bold***):
DoF Spaces
----------
Contains: LinAlg code for all macros, DataHandling, PackInfo, Specialized...We want to modularize our framework to speed up compilation and to get a better code structure.
Current proposal (modules are ***bold***):
DoF Spaces
----------
Contains: LinAlg code for all macros, DataHandling, PackInfo, Specialized Indexing
* ***vertexdofspace***
* ***edgedofspace***
* ***facedofspace***
* ***celldofspace***
Composites
----------
Contains: Function, FunctionTraits, Operators (mixed and equal level),
* ***transferoperators*** (Vertex2Vertex, Vertex2Edge, ...)
* ***operators*** (P1Operator, P2Operator, ...)
* ***functionspaces*** (P1, P2, P1Bubble, ...)
* ***solvers*** (CG, MinRes)
Indexing
--------
Contains: generalized indexing for all macro primitives
* ***indexing***
Topology
--------
Contains: Primitives, Storage, MeshInfo, Communication, PrimitiveData, PrimitiveID
* ***topology***
Common
------
Contains: everything else (until more modules are created) e.g. VTK, StencilDirections, LevelInfo, ...
* ***common***
Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/69Blending tests take too long2018-04-28T15:23:14+02:00Nils KohlBlending tests take too longUsing a debug build the blending tests take far(!) more than 10 seconds for each test case.
This should be reduced by a factor of 10 at least in my opinion.
Otherwise the build -> test -> refactor pipeline takes too long.
During CI as w...Using a debug build the blending tests take far(!) more than 10 seconds for each test case.
This should be reduced by a factor of 10 at least in my opinion.
Otherwise the build -> test -> refactor pipeline takes too long.
During CI as well as during developmentDaniel DrzisgaDaniel Drzisgahttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/43Convenience functions for setup2018-03-01T09:38:24+01:00Nils KohlConvenience functions for setupFor novice users it is currently cumbersome to get the setup phase right (mesh -> setupstorage -> storage etc.).
There should be convenience functions for thatFor novice users it is currently cumbersome to get the setup phase right (mesh -> setupstorage -> storage etc.).
There should be convenience functions for thathttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/59Upgrade generated operators to Fenics version 2017.2.02018-02-08T10:52:51+01:00Daniel DrzisgaUpgrade generated operators to Fenics version 2017.2.0Daniel DrzisgaDaniel Drzisgahttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/58Print more meaningful error message when function memory on a level is access...2018-02-08T08:54:24+01:00Daniel DrzisgaPrint more meaningful error message when function memory on a level is accessed that was not allocatedCurrently, when a level for which no function memory was allocated is accessed, an `std::out_of_range'` exception is thrown instead of catching the error and printing a nice message.Currently, when a level for which no function memory was allocated is accessed, an `std::out_of_range'` exception is thrown instead of catching the error and printing a nice message.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/35First experiences with build process2017-10-12T13:43:03+02:00Marcus MohrFirst experiences with build processHi,
as I have just started to play a little with the actual tinyhhg software and to some extent represent the *enduser faction* I thought I'd report here on my experiences so far. These are probably mostly dominated by the following two...Hi,
as I have just started to play a little with the actual tinyhhg software and to some extent represent the *enduser faction* I thought I'd report here on my experiences so far. These are probably mostly dominated by the following two facts. In our group we are running Debian Linux currently still using *Jessie*. Hence the actual system stuff sometimes is pretty old. Same as the LRZ we employ *environment modules* for updated software, compiler and library versions, if these are not available as backports for Jessie. The other aspect is that I am a novice to CMake, having just gotten used to Scons for old HHG.
1. Using CMake initially failed because Jessie's version 3.0.2 was considered to be too old. Fortunately 3.6.2 was available as backport. So this is settled.
2. CMake does not seem to work together in a transparent fashion with environment modules. Although I loaded the module for GNU 7.2.0 it wanted to use the system compiler /usr/bin/c++ which embarassingly is GNU 4.9.2
```
cmake ../tinyHHG/ -DWALBERLA_DIR=../walberla
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
```
Building that way fails in tinyhhg_core. But that can hardly be blamed on the software.
3. Fixed this problem by setting two environment variables (excuse the syntax I use tcsh :older_man_tone2:)
```tcsh
module load gcc/7.2.0
setenv CC gcc
setenv CXX g++
cmake ../tinyHHG/ -DWALBERLA_DIR=../walberla
```
does the trick
```
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: /opt/software/gcc/7.2.0/bin/gcc
-- Check for working C compiler: /opt/software/gcc/7.2.0/bin/gcc -- works
```
**Is this the preferred way to do this with CMake, or would there be a better alternative?**
4. Unfortunately, while tinyhhg_core appears to build, the apps fail due to an issue with boost_regex. I receive the following type of linker error:
```
/opt/software/gcc/7.2.0/bin/g++ -std=c++11 -Wall -Wconversion -Wshadow -Wfloat-equal -Wextra -pedantic -D_GLIBCXX_USE_CXX11_ABI=1 -pthread -O3 -DNDEBUG CMakeFiles/block_cg.dir/block_cg.cpp.o -o block_cg -rdynamic ../src/tinyhhg_core/libtinyhhg_core.a ../extern/fmt-3.0.1/fmt/libfmt.a ../walberla/src/core/libcore.a ../src/tinyhhg_core/libtinyhhg_core.a ../extern/fmt-3.0.1/fmt/libfmt.a ../walberla/src/core/libcore.a ../src/tinyhhg_core/libtinyhhg_core.a ../extern/fmt-3.0.1/fmt/libfmt.a ../walberla/src/core/libcore.a -lboost_chrono -lboost_filesystem -lboost_system -lboost_thread -lboost_regex -lboost_date_time -lboost_atomic -lpthread -lmpi -ldl -lhwloc -lmpi_cxx -lmpi -ldl -lhwloc -lmpi_cxx
CMakeFiles/block_cg.dir/block_cg.cpp.o: In function `__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > boost::re_detail::re_is_set_member<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> >, unsigned int>(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::re_detail::re_set_long<unsigned int> const*, boost::re_detail::regex_data<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, bool)':
block_cg.cpp:(.text._ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SH_SH_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb[_ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SH_SH_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb]+0x154): undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform_primary[abi:cxx11](char const*, char const*) const'
block_cg.cpp:(.text._ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SH_SH_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb[_ZN5boost9re_detail16re_is_set_memberIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEjEET_SH_SH_PKNS0_11re_set_longIT2_EERKNS0_10regex_dataIT0_T1_EEb]+0x3d8): undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform[abi:cxx11](char const*, char const*) const'
```
Now I am not 100% sure. Is this another version problem? My system boost installation is 1.55.0 and as boost_regex seems to be a part of boost that is not header-only, it was built with GNU 4.9.2. I'll next check out how this works on my laptop which runs Kubuntu 16.04 LTS.
Cheers
Marcushttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/36Improve README2017-10-02T17:36:49+02:00Nils KohlImprove READMEWe need a better readme file for the gitlab overview page:
* improving build instructions
* dependency overview
* some introduction
* links to documentation and maybe important referencesWe need a better readme file for the gitlab overview page:
* improving build instructions
* dependency overview
* some introduction
* links to documentation and maybe important referencesNils KohlNils Kohl