dune-fufem issueshttps://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues2023-01-05T11:52:42Zhttps://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/24Transfer dune-fufem to dune-project.org2023-01-05T11:52:42ZgraeserTransfer dune-fufem to dune-project.orgThis issue if for discussing/documenting the move of the project.
# Why move?
There's several good reasons to move dune-fufem to dune-project.org, e.g.:
* All maintainers have left FU Berlin.
* It simplifies contribution by others, sin...This issue if for discussing/documenting the move of the project.
# Why move?
There's several good reasons to move dune-fufem to dune-project.org, e.g.:
* All maintainers have left FU Berlin.
* It simplifies contribution by others, since people don't need FU-specific gitlab accounts.
* We should stop using FU's CI resources.
* There's more CI resources available at dune-project.org.
A potential disadvantage is that the current location git.imp.fu-berlin.de provides the enterprise version of gitlab. However, we didn't use enterprise features anyway, so that's no problem.
# Related issues
Since agnumpde/dune-matrix-vector is required by dune-fufem, this should also be moved, ideally first.
# ToDo
* [x] Decide in which group of https://gitlab.dune-project.org the projects should be located.
There's no top-level group for discretization modules and dune-fem and pdelab have their own groups. So probably we should have our own, too. (The group should be named `fufem`.)
* [x] Investigate how users are mapped when exporting/importing gitlab projects. (Mapping is done via public e-mail address if import is done by an admin user. This will preserve most users correctly. Others are associated to the importing admin account.)
* [x] Create suitable group at gitlab.dune-project.org
* [ ] dune-matrix-vector
* [x] Export project from https://git.imp.fu-berlin.de/agnumpde/dune-matrix-vector
* [x] Import project to https://gitlab.dune-project.org
* [x] Check if import worked properly including: Issues, MRs, matching of user names
* [x] Check if CI works
* [x] Archive project https://git.imp.fu-berlin.de/agnumpde/dune-mat
* [ ] dune-fufem
* [ ] Update location of dune-matrix-vector in .gitlab-ci.yml
* [x] Export project from https://git.imp.fu-berlin.de/agnumpde/dune-matrix-vector
* [x] Import project to https://gitlab.dune-project.org
* [x] Check if import worked properly including: Issues, MRs, matching of user names
* [x] Check if CI works
* [ ] Archive project https://git.imp.fu-berlin.de/agnumpde/dune-matrix-vector
* [ ] Announce move on dune-fufem user list
* [x] Announce that the projects will be moved
* [ ] Announce that the move is donehttps://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/23UFL like assembler framework2021-11-09T01:07:42ZgraeserUFL like assembler frameworkI played around with a simple UFL-like framework for defining assemblers. It turns out that this nicely interacts with the nested dune-functions bases.
To be more flexible while playing, it's in a separate project https://git.imp.fu-ber...I played around with a simple UFL-like framework for defining assemblers. It turns out that this nicely interacts with the nested dune-functions bases.
To be more flexible while playing, it's in a separate project https://git.imp.fu-berlin.de/agnumpde/dune-fufem-forms so far.
The whole implementation is essentially in the forms.hh header. Furthermore these are copies of the `stokes-taylorhood`, `poisson-pq2`, and `poisson-mfem` examples from dune-functions. For comparison they contain the new and old assembly code. In a nut shell you can do the following:
* Poisson with PQ2-discretization
```cpp
auto v = testFunction(basis);
auto u = trialFunction(basis);
auto f = Coefficient(rhsFunction);
auto a = integrate(dot(grad(v), grad(u)));
auto b = integrate(f*v);
// [...] Create global matrix, rhs, global dune-fufem assemblers
operatorAssembler.assembleBulk(matrixBackend, a);
functionalAssembler.assembleBulk(rhsBackend, b);
```
* Poisson problems with mixed RT/Lagrange-discretization
```cpp
auto fluxBasis = Functions::subspaceBasis(basis, _0);
auto pressureBasis = Functions::subspaceBasis(basis, _1);
auto sigma = trialFunction(fluxBasis);
auto u = trialFunction(pressureBasis);
auto tau = testFunction(fluxBasis);
auto v = testFunction(pressureBasis);
auto A = integrate(dot(sigma, tau) + div(tau)*u + div(sigma)*v);
// [...]
operatorAssembler.assembleBulk(matrixBackend, A);
```
* Stokes problem with Taylor-Hood discretization
```cpp
auto velocityBasis = Functions::subspaceBasis(taylorHoodBasis, _0);
auto pressureBasis = Functions::subspaceBasis(taylorHoodBasis, _1);
auto u = trialFunction(velocityBasis);
auto p = trialFunction(pressureBasis);
auto v = testFunction(velocityBasis);
auto q = testFunction(pressureBasis);
auto A = integrate( dot(grad(u), grad(v)) + div(u)*q + div(v)*p );
// [...]
operatorAssembler.assembleBulk(matrixBackend, A);
```
Non-constant coefficients should also work but are not tested so far.
This is still WIP but works surprisingly nicely (with only about 700 loc). If there's interest, we can move this to dune-fufem. Current restrictions are:
* You need a patch in dune-common to make `dot` unambiguous.
* In a special case (dot-product on matrix-valued gradient for power of scalar space) this up to 40% slower, because it currently does not take advantage of the tensor-basis structure and multiplies many zeros (*). Writing the sum of scalar dot products explicitly avoids this.
Up to one exception (see (*) above) this is even faster than the hand-written implementations in the dune-functions examples.https://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/14SubgridXYFunctionalAssemblerTest broken for ALUGrid in 3d2023-01-04T20:23:58ZmaxkaSubgridXYFunctionalAssemblerTest broken for ALUGrid in 3dThis suggests strongly that there is an issue with the `SubgridL2FunctionalAssembler` or the way it is tested.
The test for `SubgridH1FunctionalAssembler` fails for `ALUGrid<3, 3, simplex, nonconforming>` but this might relate to issues...This suggests strongly that there is an issue with the `SubgridL2FunctionalAssembler` or the way it is tested.
The test for `SubgridH1FunctionalAssembler` fails for `ALUGrid<3, 3, simplex, nonconforming>` but this might relate to issues with ALUGrid that exist by the time of this writing.https://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/11Ambiguous namespace in basisgridfunction.hh2020-04-08T11:14:47Zlh1887Ambiguous namespace in basisgridfunction.hhIn `functions/basisgridfunction.hh` there is a `namespace Functions` defined. However, if one is using `using namespace Dune`, what is probably quite common in user code, this may lead to ambiguities since in dune-functions often a names...In `functions/basisgridfunction.hh` there is a `namespace Functions` defined. However, if one is using `using namespace Dune`, what is probably quite common in user code, this may lead to ambiguities since in dune-functions often a namespace `Dune::Functions` is used. I would therefore suggest to rename the namespace in the fufem code, however, I don't want to break existing user code of others.https://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/10Create some efficient mechanism to represent a SubgridFunction on its HostGrid2023-01-04T09:14:58ZmaxkaCreate some efficient mechanism to represent a SubgridFunction on its HostGridWrite the wrapper that is needed to employ the existing CoarseGridFunctionWrapper.
This wrapper should essentially transfer the domain of definition and transmit HostGrid to Subgrid entities for evaluation.Write the wrapper that is needed to employ the existing CoarseGridFunctionWrapper.
This wrapper should essentially transfer the domain of definition and transmit HostGrid to Subgrid entities for evaluation.maxkamaxkahttps://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/9Fix, remove, or extract `BoundaryPatch::getPatchBoundaryVertices()` and `Boun...2017-07-15T11:52:25ZgraeserFix, remove, or extract `BoundaryPatch::getPatchBoundaryVertices()` and `BoundaryPatch::getPatchBoundaryEdges()`Both methods rely on the consistency of `IndexSet::subIndex()` and `ReferenceElement::subEntity()` which is not guaranteed by the grid interface. IMHO we should either fix or remove these methods. At least we should extract them from the...Both methods rely on the consistency of `IndexSet::subIndex()` and `ReferenceElement::subEntity()` which is not guaranteed by the grid interface. IMHO we should either fix or remove these methods. At least we should extract them from the class and make them free functions and possibly add a list of grids where this
assumption is true.https://git.imp.fu-berlin.de/agnumpde/dune-fufem/-/issues/8BoundaryPatch::intersect() is broken2023-01-04T09:16:39ZgraeserBoundaryPatch::intersect() is brokenThe result of this method can contain more faces than the true intersection because it relies on `BoundaryPatchEnclosingVerticesProperty`. As a consequence `boundaryPatch.intersect(boundarypatch)` will not always yield an identical copy...The result of this method can contain more faces than the true intersection because it relies on `BoundaryPatchEnclosingVerticesProperty`. As a consequence `boundaryPatch.intersect(boundarypatch)` will not always yield an identical copy. If, e.g., __all but a single__ face are contained in `boundaryPatch` then the result of `boundaryPatch.intersect(boundarypatch)` will contain __all__ faces.