amdis issueshttps://gitlab.math.tu-dresden.de/groups/amdis/-/issues2019-03-26T09:50:28Zhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/2GradientAtQP is broken2019-03-26T09:50:28ZPraetorius, SimonGradientAtQP is brokenWhen calculating the gradient of a gridFunction I get rubbish. There is something broken.When calculating the gradient of a gridFunction I get rubbish. There is something broken.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/3GlobalBasis transfer in grid change2019-08-28T11:41:54ZPraetorius, SimonGlobalBasis transfer in grid changeIf the grid changes and one uses the `ProblemStat` adapt methods, the corresponding GlobalBasis of the ProblemStat is automatically updated during. But what if there are more than one basis stored in the the Problem. (This might be quite...If the grid changes and one uses the `ProblemStat` adapt methods, the corresponding GlobalBasis of the ProblemStat is automatically updated during. But what if there are more than one basis stored in the the Problem. (This might be quite useful to describe some coefficients in the PDE). Then, this basis also has to be updated after the grid has changed.
I would propose to provide kind of a registration method for GlobalBases, similar to the `attach()` method for `DOFVector`s. This could be achieved, by using some kind of type-erasure, since only the `update(GridView)` method is required to be implemented by the Basis to update.
Maybe we can do the same for the DOFVector. Instead of requiring that it is derived from `DOFVectorInterface`, we could specify the methods need for the adaption step and provide a type-erasure storage. (similar to `std::function`)https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/4Parallel Linear Algebra Features2022-02-04T22:40:02ZMüller, FelixParallel Linear Algebra FeaturesThis lists all missing features and to-dos for the implementation of parallel linear algebra.
* [x] General interface
* [x] Parallel examples/ tests
* [x] ~~MTL~~
* [ ] ISTL
* [x] Overlapping Schwarz
* [ ] Nonoverlapping Schwa...This lists all missing features and to-dos for the implementation of parallel linear algebra.
* [x] General interface
* [x] Parallel examples/ tests
* [x] ~~MTL~~
* [ ] ISTL
* [x] Overlapping Schwarz
* [ ] Nonoverlapping Schwarz
* [ ] Case `overlapSize + ghostSize == 0`
* [x] Bases with more than one DoF per entity
* [x] e.g. Lagrange order 3+, edge/face twists
* [x] LagrangeDG
* [x] More parallel preconditioners
* [x] ~~EIGEN~~
* [x] PETSchttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/5Boundary IDs from Reader2020-11-07T12:00:37ZPraetorius, SimonBoundary IDs from ReaderThere are problems with the boundary manager and the boundary IDs when read from file, i.e. the number does not match. This needs some checking.There are problems with the boundary manager and the boundary IDs when read from file, i.e. the number does not match. This needs some checking.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/6No-MPI problems2019-12-07T15:08:56ZPraetorius, SimonNo-MPI problemsThere are some problems when compiled without MPI. This needs to be fixed.There are some problems when compiled without MPI. This needs to be fixed.Praetorius, SimonPraetorius, Simonhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/10Restructure of Assembler2021-12-07T08:19:54ZMüller, FelixRestructure of AssemblerThe current assembler structure is obscure and methods are scattered. An attempt to simplify this is to be made.
0.3:
* [ ] Move global assembly loop from `ProblemStat` to a dedicated new class (see !163)
* [ ] Add interface to use co...The current assembler structure is obscure and methods are scattered. An attempt to simplify this is to be made.
0.3:
* [ ] Move global assembly loop from `ProblemStat` to a dedicated new class (see !163)
* [ ] Add interface to use constraints in assembly
After 0.3:
* [ ] Find a better abstraction for `GridFunctionOperator`, `Assembler`, `OperatorList`
* [ ] (optional) Discuss compatibility with `PDELabs`Müller, FelixMüller, Felixhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/11Dirichlet BoundaryConditions with general value gridfunction2020-11-06T14:51:05ZPraetorius, SimonDirichlet BoundaryConditions with general value gridfunctionCurrently the gridfunctions in DirichletBC are simple `std::function<Range(Domain)>`. This should be generalized to arbitrary grid functions. Maybe using the type-erased gridfunction wrapper from dune-functions.Currently the gridfunctions in DirichletBC are simple `std::function<Range(Domain)>`. This should be generalized to arbitrary grid functions. Maybe using the type-erased gridfunction wrapper from dune-functions.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/12Search for coordinates with kdtree od quad/hex trees2022-12-07T13:52:00ZPraetorius, SimonSearch for coordinates with kdtree od quad/hex treesWhen search for coordinate vectors, e.g. in periodic associations, one should not use `std::map` with a lexicographic comparison. There are always cases where this fails. Better use a data-structure that is specifically designed for this...When search for coordinate vectors, e.g. in periodic associations, one should not use `std::map` with a lexicographic comparison. There are always cases where this fails. Better use a data-structure that is specifically designed for this task. Like KDTree or QuadTrees/HexTrees. This data-structure must be added somehow to common or utility.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/13GitLab CI based on dune modules2020-07-10T19:40:21ZPraetorius, SimonGitLab CI based on dune modules### Summary
Replace the current base docker images in the CI configuration with pdelab-deps or another image that contains most of the dune modules already. Maybe configure a dependency image in the dune docker/ci for amdis.
### Details...### Summary
Replace the current base docker images in the CI configuration with pdelab-deps or another image that contains most of the dune modules already. Maybe configure a dependency image in the dune docker/ci for amdis.
### Details
The current `.gitlab-ci.yml` configuration installes all the modules again. This is very time consuming for the runners and slows down the tests.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/14Documentation of amdisproject2022-01-01T23:09:47ZPraetorius, SimonDocumentation of amdisprojectThe helperscript `amdisproject`, a modified version of the `duneproject` script is not really documented in code and in read-the-docs
- What can this script do for me?
- How to use it?
- Any requirements?
Could this bash script be rep...The helperscript `amdisproject`, a modified version of the `duneproject` script is not really documented in code and in read-the-docs
- What can this script do for me?
- How to use it?
- Any requirements?
Could this bash script be replaced by a python or cmake script?https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/15Reference to Read-The-Docs in Code2022-02-04T22:40:02ZPraetorius, SimonReference to Read-The-Docs in CodeIn the documentation files and README file there is nowhere a reference to https://amdis.readthedocs.io This needs to be changed in order to fine the generated documentation easily.In the documentation files and README file there is nowhere a reference to https://amdis.readthedocs.io This needs to be changed in order to fine the generated documentation easily.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/16Add MTL and PETSc Tests to Gitlab CI2020-12-22T16:25:17ZPraetorius, SimonAdd MTL and PETSc Tests to Gitlab CICurrently the CI system only tests the ISTL backend. So, some errors are not found automatically when changing the other backend implementations. I suggest to add pipelines for all backends, maybe with the dune master branch.
It might ...Currently the CI system only tests the ISTL backend. So, some errors are not found automatically when changing the other backend implementations. I suggest to add pipelines for all backends, maybe with the dune master branch.
It might be that we have to create our own docker image for this. Therefore, we could use the docker registry on dune-project with a modified script of docker/cihttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/18How to pass multiple tree-paths2023-05-31T15:00:47ZPraetorius, SimonHow to pass multiple tree-pathsThis Discussion is about exploring the design space for tree-paths.
A treepath is an instance of `Dune::TypeTree::HybridTreePath<I...>` where `I` is either a `Std::integral_constant<std::size_t,i>` or an `std::size_t`, representing a c...This Discussion is about exploring the design space for tree-paths.
A treepath is an instance of `Dune::TypeTree::HybridTreePath<I...>` where `I` is either a `Std::integral_constant<std::size_t,i>` or an `std::size_t`, representing a compile-time index or a run-time index. The following methods exist to pass tree-paths to the function `addMatrixOperator(...)`:
### For single indices
```c++
addMatrixOperator(op, 0, 1); // single run-time index
addMatrixOperator(op, _0, _1); // single compile-time index
addMatrixOperator(op, 0_c, 1_c); // single compile-time index using index constant literal
addMatrixOperator(op, 0_tp, 1_tp); // single compile-time index using tree-path literal
addMatrixOperator(op, makeTreePath(0), makeTreePath(_1)); // single index using the makeTreePath function
```
### For multiple indices
```c++
addMatrixOperator(op, makeTreePath(0,_1), makeTreePath(_1,2));
addMatrixOperator(op, std::tuple{0,_1}, std::tuple{_1,2});
addMatrixOperator(op, 01_tp, 12_tp);
```
### Iterating over tree-path indices
```c++
for (std::size_t i = 0; i < 10; ++i)
addMatrixOperator(op, makeTreePath(i,_1), makeTreePath(_1,i));
Ranges::forIndices<10>([&](auto _i) {
addMatrixOperator(op, makeTreePath(0,_i), makeTreePath(_i,0));
});
```
### Extensions:
If all indices in the tree-path are run-time indices: use `std::initializer_list<T>` or `std::array`
```c++
addMatrixOperator(op, {0,1}, {1,2});
```
for the iteration, a `forEach` method in the static/dynamic range class could be useful:
```c++
range(10).forEach([&](auto i) {
addMatrixOperator(op, makeTreePath(i,_1), makeTreePath(_1,i));
});
range(10_c).forEach([&](auto _i) {
addMatrixOperator(op, makeTreePath(0,_i), makeTreePath(_i,0));
});
```
Is it possible to use a run-time index for a composite tree? Maybe if the TreeContainer recursively provides a `FakeContainer` in case someone accesses the the container in a wrong way(?) Not sure whether this would be possible.https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/19Usage of PeriodicBasis together with PowerBasis leads to Segmentation Fault w...2023-09-29T14:09:02ZPorrmann, MaikUsage of PeriodicBasis together with PowerBasis leads to Segmentation Fault while assemblingThe `introduce-periodic-basis` branch of dune-functions (see https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/263) adds a periodic Basis Wrapper to dune-functions. While it works in AMDiS out of the box for scalar ...The `introduce-periodic-basis` branch of dune-functions (see https://gitlab.dune-project.org/staging/dune-functions/-/merge_requests/263) adds a periodic Basis Wrapper to dune-functions. While it works in AMDiS out of the box for scalar Functionspaces, vectorvalued Functionspaces created with power<>() lead to a Segmentation fault while assembling.
Minimal Example:
~~~
#include <config.h>
#include <amdis/AMDiS.hpp>
#include <amdis/LocalOperators.hpp>
#include <dune/grid/onedgrid.hh>
#include <dune/functions/functionspacebases/defaultglobalbasis.hh>
#include <dune/functions/functionspacebases/lagrangebasis.hh>
#include <dune/functions/functionspacebases/periodicbasis.hh>
using namespace AMDiS;
int main(int argc, char** argv)
{
Environment env(argc, argv);
Dune::OneDGrid grid(10, 0.0, 1.0);
using namespace Dune::Functions::BasisFactory;
PeriodicIndexSet periodicIndexSet; // Doesn't need to be filled to reproduce the Error
ProblemStat prob("prob", grid, power<3>(periodic(lagrange<1>(), periodicIndexSet), flatLexicographic()));
prob.initialize(INIT_ALL);
for (int i = 0; i<3; i++){
prob.addMatrixOperator(sot(1.0), makeTreePath(i), makeTreePath(i));
}
AdaptInfo adaptInfo("adapt");
prob.assemble(adaptInfo);
prob.solve(adaptInfo);
}
~~~
Tested with ISTL and PETSc
Errormessage:
~~~
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Address not mapped (1)
Failing at address: 0xc
~~~
Complete Errormessage with hardly readable stacktrace [errormessage.txt](/uploads/2c8eeb4cb487545d351afeb96ccb7fa9/errormessage.txt)
Project was setup with amdisproject using the dune modules: amdis dune-common dune-geometry dune-localfunctions dune-typetree dune-uggrid dune-grid dune-istl dune-functions dune-spgrid dune-vtkhttps://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/20interpolate_noalias with PETSc-Backend2021-12-09T14:08:37ZKrause, Veitinterpolate_noalias with PETSc-BackendIn Code below `interpolate_noalias` doesn't work in case of using the PETSc-Backend. The issue is in line 55. Using the function in line 27 or 37 works.
The code runs without an error but in the Result you will see that the interpolatio...In Code below `interpolate_noalias` doesn't work in case of using the PETSc-Backend. The issue is in line 55. Using the function in line 27 or 37 works.
The code runs without an error but in the Result you will see that the interpolation is not acting on the DOFs correctly.
With the following changes the code works:
* Compiling amdis with dune-istl
* using `interpolate` in line 55
With the following changes the code fails also:
* using first oder third order dune-curvedgrid
* refine the grid
* `tag::average{}` instead of `tag::assign{}`
```
#include <config.h>
#include <iostream>
#include <amdis/AMDiS.hpp>
#include <amdis/LocalOperators.hpp>
#include <amdis/ProblemStat.hpp>
#include <dune/vtk/pvdwriter.hh>
#include <dune/vtk/datacollectors/lagrangedatacollector.hh>
#include <dune/vtk/writers/vtkunstructuredgridwriter.hh>
#include <dune/common/parallel/mpihelper.hh>
#include <dune/curvedgrid/curvedgrid.hh>
#include <dune/foamgrid/foamgrid.hh>
using namespace AMDiS;
using namespace Dune::Functions::BasisFactory;
int main(int argc, char** argv)
{
Environment env(argc, argv);
using gridType = Dune::FoamGrid<2,3> ;
auto refGridPtr = MeshCreator<gridType>::create("mesh");
DOFVector surfaceDofVec{refGridPtr->leafGridView(), power<3>(lagrange(2))};
valueOf(surfaceDofVec).interpolate_noalias([](auto const& x){return x / x.two_norm(); } , tag::assign{});
Dune::CurvedGrid grid{*refGridPtr, valueOf(surfaceDofVec)};
ProblemStat curv("curv",grid, lagrange(1) );
curv.initialize(INIT_ALL);
AdaptInfo adaptInfo("adapt");
// create a DOFVector representing the surface normal
DOFVector nDofVec{curv.gridView(), power<3>(lagrange(2))};
valueOf(nDofVec).interpolate_noalias([](const auto& x) { return x / x.two_norm(); } , tag::assign{});
DOFVector surfaceUpdate{curv.gridView() , power<3>(lagrange(2))};
DOFVector surfaceOldDofVec{curv.gridView() , power<3>(lagrange(2))};
// visualization of the vector field
Dune::Vtk::LagrangeDataCollector dataCollector{curv.gridView(), 2};
using Writer = decltype(Dune::VtkUnstructuredGridWriter{dataCollector});
Dune::PvdWriter<Writer> writer{dataCollector};
writer.addPointData(valueOf(nDofVec), Dune::Vtk::FieldInfo{"n", .size=3, .rangeType=Dune::Vtk::RangeTypes::VECTOR});
for (adaptInfo.setTime(adaptInfo.startTime()) ; !adaptInfo.reachedEndTime() ; adaptInfo.setTime(adaptInfo.time()+adaptInfo.timestep()) , adaptInfo.incTimestepNumber()){
writer.writeTimestep(adaptInfo.time() , "/home/veitz/output/nematodynamic/meanCurvatureFlow/meanCurvatureFlow.pvd" );
surfaceOldDofVec.impl().vector() = surfaceDofVec.impl().vector() ;
// The code line below make issues in case of interpolate_noalias
valueOf(surfaceUpdate).interpolate_noalias(valueOf(surfaceOldDofVec) + adaptInfo.timestep() * X() , tag::assign{});
//valueOf(surfaceUpdate).interpolate(valueOf(surfaceOldDofVec) + adaptInfo.timestep() * X() , tag::assign{});
// ---------------------------------------------------------
surfaceDofVec.impl().vector() = surfaceUpdate.impl().vector() ;
}
return 0;
}
```https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/21Different behaviour in usage of (1 - solution) and (1.0 - solution) while def...2021-12-09T14:10:01ZBabu, HarisankarDifferent behaviour in usage of (1 - solution) and (1.0 - solution) while defining operatorsI have a strange problem in the operators. For the below code, when I define **opMob** in line 39 with (1 - phi), there is no evolution observed for the cahn-hilliard model and if I change it to (1.0 - phi), the model behaves as expected...I have a strange problem in the operators. For the below code, when I define **opMob** in line 39 with (1 - phi), there is no evolution observed for the cahn-hilliard model and if I change it to (1.0 - phi), the model behaves as expected, where **phi** is one of the solution variables. Attaching the macro and init files along.
[macro.square.2d](/uploads/d2f6fe8f5a85e4b00a5d7b538bbcfb7b/macro.square.2d)[Surface_Diffusion.dat](/uploads/07a59669999ccbfdd485474071213c2d/Surface_Diffusion.dat)
```cpp
#include <amdis/AMDiS.hpp>
#include <amdis/AdaptInstationary.hpp>
#include <amdis/LocalOperators.hpp>
#include <amdis/ProblemInstat.hpp>
#include <amdis/ProblemStat.hpp>
#include <amdis/GridFunctions.hpp>
#include <amdis/Marker.hpp>
#include <dune/grid/albertagrid.hh>
using namespace AMDiS;
using Grid = Dune::AlbertaGrid<GRIDDIM, WORLDDIM>;
using Param = LagrangeBasis<Grid, 1, 1>;
int main(int argc, char** argv)
{
Environment env(argc, argv);
ProblemStat<Param> prob("ch");
prob.initialize(INIT_ALL);
ProblemInstat<Param> probInstat("ch", prob);
probInstat.initialize(INIT_UH_OLD);
AdaptInfo adaptInfo("adapt");
auto invTau = std::ref(probInstat.invTau());
auto phi = prob.solution(0);
auto phiOld = probInstat.oldSolution(0);
auto mu = prob.solution(1);
double M = Parameters::get<double>("parameters->mobility").value_or(1.0);
double eps = Parameters::get<double>("parameters->epsilon").value_or(0.02);
prob.addMatrixOperator(makeOperator(tag::test_trial{}, invTau), 0, 0);
prob.addVectorOperator(makeOperator(tag::test{}, phiOld * invTau), 0);
auto opMob = (M/eps) * 36 * pow<2>(phi) * pow<2>(1 - phi);
prob.addMatrixOperator(makeOperator(tag::gradtest_gradtrial{}, opMob), 0, 1);
prob.addMatrixOperator(makeOperator(tag::test_trial{}, 1.0), 1, 1);
prob.addMatrixOperator(makeOperator(tag::gradtest_gradtrial{}, -eps), 1, 0);
auto opFimpl = makeOperator(tag::test_trial{}, -1/eps * (36 - 216 * phi + 216 * pow<2>(phi)));
prob.addMatrixOperator(opFimpl, 1, 0);
auto opFexpl1 = makeOperator(tag::test{}, 1/eps * (36 * phi - 108 * pow<2>(phi) + 72 * pow<3>(phi)));
prob.addVectorOperator(opFexpl1, 1);
auto opFexpl2 = makeOperator(tag::test{}, -phi/eps * (36 - 216 * phi + 216 * pow<2>(phi)));
prob.addVectorOperator(opFexpl2, 1);
int ref_int = Parameters::get<int>("refinement->interface").value_or(10);
int ref_bulk = Parameters::get<int>("refinement->bulk").value_or(2);
GridFunctionMarker marker("interface", prob.grid(),
invokeAtQP([ref_int, ref_bulk](double xx) {
return xx > 0.05 && xx < 0.95 ? ref_int : ref_bulk;
}, phi));
prob.addMarker(marker);
for (int i = 0; i < 6; ++i) {
phi << [eps](auto const& x) {
using Math::sqr;
double theta = std::atan2(x[1], x[0]);
double r = (0.6 * 0.4) / std::sqrt(std::pow(0.4 * std::cos(theta), 2) + std::pow(0.6 * std::sin(theta),2));
double dist = std::sqrt(std::pow(x[0],2) + std::pow(x[1],2));
return 0.5 * (1 - std::tanh(3.0 * ((std::abs(dist) - r) / eps)));
};
prob.markElements(adaptInfo);
prob.adaptGrid(adaptInfo);
}
AdaptInstationary adapt("adapt", prob, adaptInfo, probInstat, adaptInfo);
adapt.adapt();
return 0;
}
```https://gitlab.math.tu-dresden.de/amdis/amdis-core/-/issues/23Error while compiling when using gradientOf for expressions with solution var...2021-12-09T15:49:48ZBabu, HarisankarError while compiling when using gradientOf for expressions with solution variableFor the following code doesn't compile with an error: **no matching function for call to ‘get<0>(std::integer_sequence<long unsigned int, 0, 1>&)’**
```cpp
auto phi = prob.solution(0);
auto opMob = gradientOf(36 * pow<2>(phi) * pow<2>(1...For the following code doesn't compile with an error: **no matching function for call to ‘get<0>(std::integer_sequence<long unsigned int, 0, 1>&)’**
```cpp
auto phi = prob.solution(0);
auto opMob = gradientOf(36 * pow<2>(phi) * pow<2>(1 - phi));
```
It works for
```cpp
auto opMob = gradientOf(phi);
```
but gives the same error for
```cpp
auto opMob = gradientOf(36 * phi);
```
and
```cpp
auto opMob = gradientOf(pow<2>(phi));
```