hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2024-02-13T16:33:09+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/244Shadowing makes pipeline fail with FOG operators in app directory2024-02-13T16:33:09+01:00Marcus MohrShadowing makes pipeline fail with FOG operators in app directoryHi,
I am encountering pipeline failure due to shadowing variable declarations in case of a generated operator placed inside an app's directory:
```
../../../apps/nlDiffusion/P1ElementwiseNonlinearDiffusionNewtonGalerkin.cpp:971:26: erro...Hi,
I am encountering pipeline failure due to shadowing variable declarations in case of a generated operator placed inside an app's directory:
```
../../../apps/nlDiffusion/P1ElementwiseNonlinearDiffusionNewtonGalerkin.cpp:971:26: error: declaration shadows a local variable [-Werror,-Wshadow]
const real_t tmp_7_WHITE_UP = tmp_6_WHITE_UP * 0.050086823222829389;
^
```
See e.g. pipeline [#62046](https://i10git.cs.fau.de/hyteg/hyteg/-/pipelines/62046)Fabian BöhmFabian Böhmhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/204P2Function::prolongateP1ToP2() is broken2023-04-14T10:49:17+02:00Marcus MohrP2Function::prolongateP1ToP2() is brokenHi,
the method `prolongateP1ToP2()` of the `P2Function` class seems to not work correctly. It is supposed to fill the P2Function object with data obtained from embedding the given P1Function into the corresponding P2 FE-space on the sam...Hi,
the method `prolongateP1ToP2()` of the `P2Function` class seems to not work correctly. It is supposed to fill the P2Function object with data obtained from embedding the given P1Function into the corresponding P2 FE-space on the same mesh and refinement level.
The following figure is the result of embedding a constant P1 function. As one can see there are errors at the macro edges. These seem to be associated with the left- and right-most edgeDoF at the edge:
![P2Function__prolongateP1ToP2-error](/uploads/84146e5e8a5a29468c7df55b04cb75ce/P2Function__prolongateP1ToP2-error.png)
Note that while the method is tested as part of `P2P1TransferTest`, that test appears to only test inside a single macro face, while using zero values at edges and vertices. This would explain why it does not catch the problem.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/196Global vs. Local Operation Error in P0Function2023-03-23T16:45:07+01:00Marcus MohrGlobal vs. Local Operation Error in P0FunctionHi,
implementation of [`dotGlobal` and `dotLocal`](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/src/hyteg/p0functionspace/P0Function.hpp#L203-211) seems to mix up delegation, i.e. `P0Function::dotGlobal()` calls `DGFunction::dotLo...Hi,
implementation of [`dotGlobal` and `dotLocal`](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/master/src/hyteg/p0functionspace/P0Function.hpp#L203-211) seems to mix up delegation, i.e. `P0Function::dotGlobal()` calls `DGFunction::dotLocal()` while
`P0Function::dotLocal()` calls `DGFunction::dotGlocal()`. Seems dubious, at least no POLA :wink: .
If it's really wrong, we need to have a parallel test, as the pipeline does not catch it.
Cheers
MarcusPonsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/197readd petsc+trilinos tests for intel2023-01-27T09:18:47+01:00Dominik Thoennesdominik.thoennes@fau.dereadd petsc+trilinos tests for intelThe petsc and trilinos test are currently disabled for the "old" intel compilers
This has to be fixed in the docker images firstThe petsc and trilinos test are currently disabled for the "old" intel compilers
This has to be fixed in the docker images firsthttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/193Add GCC 12 to pipeline2023-01-24T15:19:40+01:00Marcus MohrAdd GCC 12 to pipelineHi,
IMHO we should add GCC version 12 to our test pipeline. I have built the testsuite today using *12.2.0* on *Debian GNU/Linux 11 (bullseye)* and am seeing a whole lot of warnings. Some of those, but not all, are related to the rece...Hi,
IMHO we should add GCC version 12 to our test pipeline. I have built the testsuite today using *12.2.0* on *Debian GNU/Linux 11 (bullseye)* and am seeing a whole lot of warnings. Some of those, but not all, are related to the recent replacement of our own matrix class by eigen !550:
| merge | lines of output | raw output |
| :---: | --------------: | :---: |
| 7748e4e8f | 1298669 | [LOG-GCC12-for-7748e4e8f.txt](/uploads/690ed8d13aeaea70ba3987948f561397/LOG-GCC12-for-7748e4e8f.txt) |
| 7f2345128 | 291369 | [LOG-GCC12-for-7f2345128.txt](/uploads/b750ed522d7f6465cba14001241ee2fd/LOG-GCC12-for-7f2345128.txt) |
Cheers
MarcusDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/168Bump code coverage in forms2022-02-04T12:44:34+01:00Nils KohlBump code coverage in formsLooking at https://hyteg.pages.i10git.cs.fau.de/-/hyteg/-/jobs/684751/artifacts/coverage/coverage.html it seems that we should probably write/augment 1-2 tests so that all `*epsilonvar*` and `*epslioncc*` forms are at least executed once...Looking at https://hyteg.pages.i10git.cs.fau.de/-/hyteg/-/jobs/684751/artifacts/coverage/coverage.html it seems that we should probably write/augment 1-2 tests so that all `*epsilonvar*` and `*epslioncc*` forms are at least executed once. This would cover roughly 10k - 20k lines of 150k atm.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/147FP exception in test with clang 102021-06-04T10:44:41+02:00Marcus MohrFP exception in test with clang 10Hi,
I'm having trouble with clang-10. The extended HytegVsFenicsFormTest fails in the [pipeline](https://i10git.cs.fau.de/hyteg/hyteg/-/pipelines/31556). The problem is that, at least to me, this seems that this error is introduced by t...Hi,
I'm having trouble with clang-10. The extended HytegVsFenicsFormTest fails in the [pipeline](https://i10git.cs.fau.de/hyteg/hyteg/-/pipelines/31556). The problem is that, at least to me, this seems that this error is introduced by this specific clang version in the optimisation. The problem does neither occur in **Debug mode** nor with **GCC**.
I can reproduce the problem using
- cmake 10.0
- CMAKE_BUILD_TYPE = RelWithDebInfo
- SHA 52ebc999
Running the executable through gdb I get
```
Thread 1 "HytegVsFenicsFo" received signal SIGFPE, Arithmetic exception.
hyteg::P2Form_epsilon_11::evalQuadraturePoint2D (this=0x7fffffffd940, x_hat=..., x_tilde=..., coords=..., DF=...,
w=0.16666666666666666, elMat=...)
at .../HyTeG/src/hyteg/forms/form_hyteg_generated/P2FormEpsilon.hpp:43
43 real_t tmp11 = 1/(std::pow(tmp10, 2)*std::pow(tmp9, 2));
```
This makes sense as in the pipeline a division-by-zero was reported. However, when I look at the input arguments I get
```
(gdb) info args
this = 0x7fffffffd940
x_hat = @0x7fffffffd680: {x_ = {0, 0.5, 0}}
x_tilde = @0x7fffffffd6a0: {x_ = {-0.84999999999999998, -0.75, 0}}
coords = @0x7fffffffddd0: {_M_elems = {{x_ = {-0.69999999999999996, -2, 0}}, {x_ = {1, 1, 0}}, {x_ = {-1, 0.5, 0}}}}
DF = @0x7fffffffd6c0: {static Size = 4, x = {1, 0, 0, 1}}
w = 0.16666666666666666
elMat = @0x7fffffffdc40: {static Size = 36, x = {0.14563106796116504, 0.061488673139158581, 0.20711974110032361, -0.41423948220064721,
-0.41423948220064721, 0.41423948220064721, 0.061488673139158581, 0.40744336569579287, 0.46893203883495144, -0.93786407766990287,
-0.93786407766990287, 0.93786407766990287, 0.20711974110032361, 0.46893203883495144, 0.6760517799352751, -1.35210355987055,
-1.35210355987055, 1.35210355987055, -0.41423948220064721, -0.93786407766990287, -1.35210355987055, 2.7042071197411004,
2.7042071197411, -2.7042071197411, -0.41423948220064721, -0.93786407766990287, -1.35210355987055, 2.7042071197411,
2.7042071197411004, -2.7042071197411, 0.41423948220064721, 0.93786407766990287, 1.35210355987055, -2.7042071197411,
-2.7042071197411, 2.7042071197411004}}
```
from which I can check that neither tmp9 nor tmp10 should have zero value. Trying to check their values I get
```
tmp9 = <optimized out>
tmp10 = <optimized out>
```
which leads me to assume that the problem is optimisation related.
As I cannot reproduce the problem with clang-8 I assume it might be related to clang-10 only.
Suggestions anyone?
Cheers
Marcushttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/131ElementwiseOperatorPetscTest runs wrong test2020-09-04T18:20:06+02:00Marcus MohrElementwiseOperatorPetscTest runs wrong testHi,
I just discovered why the ```ElementwiseOperatorPetscTest``` fails, when I invoke it manually, but runs through in the pipeline. Reason is that in the testsuite it actually runs ```PetscTest``` due to an error in [CMakeLists.txt](ht...Hi,
I just discovered why the ```ElementwiseOperatorPetscTest``` fails, when I invoke it manually, but runs through in the pipeline. Reason is that in the testsuite it actually runs ```PetscTest``` due to an error in [CMakeLists.txt](https://i10git.cs.fau.de/hyteg/hyteg/-/blob/18594f8a6e038ac24656767fdaa608caeea3e1c5/tests/hyteg/CMakeLists.txt#L577).
Going to fix this now.
Cheers
MarcusMarcus MohrMarcus Mohrhttps://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/37Improve CI process2018-03-21T12:47:19+01:00Nils KohlImprove CI processIncludes:
* [x] genrated .yaml file (similar to walberla)
* [ ] ~~separate build and test step~~ (current GitLab version does not support this in a nice way)
* [x] code coverage
* [x] address sanitizerIncludes:
* [x] genrated .yaml file (similar to walberla)
* [ ] ~~separate build and test step~~ (current GitLab version does not support this in a nice way)
* [x] code coverage
* [x] address sanitizerNils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/56PointND constructor usage with initialiser list2018-02-08T16:09:02+01:00Marcus MohrPointND constructor usage with initialiser listI have an issue with constructing points using an initialiser list. I'd like to use a short form for constructing points where I only
pass the coordinates. It would be concise and intuitive to use an approach like this
````
Point2D( { 2....I have an issue with constructing points using an initialiser list. I'd like to use a short form for constructing points where I only
pass the coordinates. It would be concise and intuitive to use an approach like this
````
Point2D( { 2.0, 3.0 } )
````
That construct compiles with g++, icpc and cygwin64 and these parts in [pipeline #6872](https://i10git.cs.fau.de/terraneo/tinyhhg/pipelines/6872) greenlight. However, clang produces the warning
````
./../../src/tinyhhg_core/mesh/MeshGenRectangle.cpp:179:77: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
meshInfo.vertices_[idx] = MeshInfo::Vertex( idx, Point3D( { midx, midy, 0.0 } ), Inner );
^~~~~~~~~~~~~~~
{ }
````
which results in a failure due to the -Werror. This issue was also encountered by @daniel, see commit cffe5cc. My question is, whether me being new to the newer C++ versions, am making a conceptual error, or is this an issue with clang as seems to be indicated by
https://stackoverflow.com/questions/31555584/why-is-clang-warning-suggest-braces-around-initialization-of-subobject-wmis?
I can produce similar warnings in g++, when I enforce the -Wmissing-braces option, but that option was deliberately excluded from -Wall for C++ with GCC.
I tried to solve the problem by adding additional braces as suggested by clang, but that makes the code incompilable with g++ because it now is unsure which constructor it should invoke
````
candidate: hhg::PointND<T, N>::PointND(const hhg::PointND<T, N>&) [with T = double; long unsigned int N = 2]
PointND(const PointND& b)
candidate: hhg::PointND<T, N>::PointND(std::array<_Tp, _Nm>) [with T = double; long unsigned int N = 2]
PointND(std::array<T, N> list)
````
Any suggestions?
Cheers
Marcushttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/16Coding Conventions2017-11-15T11:10:47+01:00Nils KohlCoding ConventionsCreate coding conventions and integrate some kind of checkerCreate coding conventions and integrate some kind of checkerhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/21Create docu only on one branch2017-10-02T16:07:28+02:00Dominik Thoennesdominik.thoennes@fau.deCreate docu only on one branchCurrently the docu is always build on the latest commitCurrently the docu is always build on the latest commitDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/13Removing walberla app builds on windows2017-08-30T13:41:24+02:00Nils KohlRemoving walberla app builds on windowsIt looks like the tinyhhg pipeline builds walberla apps on Windows.
```
27>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\CL.exe /c /I"C:\cygwin64\home\build\builds\terraneo\tinyhhg\extern\fmt-3.0.1...It looks like the tinyhhg pipeline builds walberla apps on Windows.
```
27>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\CL.exe /c /I"C:\cygwin64\home\build\builds\terraneo\tinyhhg\extern\fmt-3.0.1" /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\src /I"C:\Boost\include\boost-1_63" /I"C:\Program Files (x86)\Microsoft SDKs\MPI\include" /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\build\walberla\src /IC:\cygwin64\home\build\builds\terraneo\tinyhhg\walberla\src /nologo /W4 /WX- /MP /O2 /Ob2 /D WIN32 /D _WINDOWS /D NDEBUG /D NOMINMAX /D _WIN32_WINNT=0x501 /D WINVER=0x501 /D _CRT_SECURE_NO_WARNINGS /D _SCL_SECURE_NO_WARNINGS /D BOOST_ALL_NO_LIB /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"SchaeferTurek.dir\Release\\" /Fd"SchaeferTurek.dir\Release\vc140.pdb" /Gd /TP /wd4127 /wd4512 /wd4913 /wd4702 /wd4505 /wd4503 /errorReport:queue -bigobj C:\cygwin64\home\build\builds\terraneo\tinyhhg\walberla\apps\benchmarks\SchaeferTurek\SchaeferTurek.cpp
```Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/15Build doxygen documentation via CI2017-07-26T17:12:51+02:00Nils KohlBuild doxygen documentation via CIIt would be nice to be able to access the doxygen documentation from a Pipeline as an artifact.It would be nice to be able to access the doxygen documentation from a Pipeline as an artifact.Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.de