FS issueshttps://gitlab.dune-project.org/flyspray/FS/-/issues2015-03-10T05:40:37Zhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1580FS#1580 DGF grid creator for new Yasp grid modes2015-03-10T05:40:37ZChristoph GrüningerFS#1580 DGF grid creator for new Yasp grid modes
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Mar 4, 2015 14:42 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Mar 4, 2015 14:42 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Mar 10, 2015 05:40 |
# Description
As Yasp grid gained two new modes, non-trivial origin and tensor grid, the DGF grid creator still does not support them.
For the non-trivial origin it is enough to adapt the DGF grid creator. I already crated a feature branch called
feature/dgf-yasp
Please comment. I'll merge it after a week or so.
For the tensor grid, I suggest to introduce a new block marked with the keyword "Tensor". It is followed by dimworld lines. Each line represents a tensor, i.e. contains the sorted coordinates for this dimension.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1495FS#1495 reading element data is buggy using dune-alugrid2014-09-24T19:28:25ZFlyspray ImporterFS#1495 reading element data is buggy using dune-alugrid
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Nagaiah (nagaiah.chamakuri@gmail.com) |
| Reported at | Sep 24, 2014 19:28 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Nagaiah (nagaiah.chamakuri@gmail.com) |
| Reported at | Sep 24, 2014 19:28 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Hi,
Last week I updated my all dune modules and downloaded git version of dune-alugrid.
I found that reading the element data from dgf file is buggy using ALUGRID_SIMPLEX type.
This happens when all dune modules (including dune-alugrid)
are compiled with --enable-parallel flag.
without enable-parallel flag(sequential compilation) this works fine.
reading vertex data works fine in both cases.
No issues using UG grid, this works in sequential and parallel version.
Please find attached the dgf file and
for the test case I used the example file from
dune-grid/dune/grid/io/file/dgfparser/test/main.cc
(using GRIDTYPE=ALUGRID_SIMPLEX and GRIDDIM=3)
Here you have to copy the main.cc file in to your user module and
compile using with dune-grid and dune-alugrid.
The resulting vtu file (after loading in paraview) shows that the
element data is distorted. Please find the attached two figures
what it should look like and should not.
seq.png : it should look like this
par.png : odd solution after reading element data with ALUGrid
tested with latest git version of all dune code modules and dune-alugrid.
Compiler is : gcc-4.7.2
# Attachments
* ![seq](/uploads/9da49baafb7e12697a901dc4ece8c254/seq.png)
* ![par](/uploads/46cd97eac57d67836d99f838bc8872e1/par.png)
* [test.dgf](/uploads/efb338c07addd5b0d389770a7290fcf6/test.dgf)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1494FS#1494 Expand the interface of BackupRestoreFacility2014-09-24T18:48:34ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deFS#1494 Expand the interface of BackupRestoreFacility
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Sep 24, 2014 18:48 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Sep 24, 2014 18:48 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
While implementing a BackupRestoreFacility for YaspGrid I tripped over a small detail the interface.
The interface allows me to create a set of files with names based on a given name and some implementation specific extensions. I want to use the rank as such extension for a parallel grid.
When I want to restore such grid, I need to know the rank of my process to pick the correct file. To get it, I need to know which communicator the grid is supposed to be attached to. With the current interface, I can only assume MPI_COMM_WORLD to be that communicator.
I therefore propose to add a second parameter with the communicator to the restore method(s), which defaults to MPI_COMM_WORLD.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1289FS#1289 PyramidP*LocalFiniteElement evaluateJacobian() is buggy2014-06-21T15:11:26ZCarsten Gräsergraeser@math.fau.deFS#1289 PyramidP*LocalFiniteElement evaluateJacobian() is buggy
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 29, 2013 14:25 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating Syst...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 29, 2013 14:25 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Jun 21, 2014 15:11 |
# Description
The finite difference check of evaluateJacobian() in test-localfe reveals that this method does not conform with the implentation of evaluate(). Since evaluate() and interpolate() are matching the error seems to be in the jacobian.
If this is related to singular jacobians for pyramid elements we should adjust the test accordingly.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1444FS#1444 public/protected types in GridView2014-03-24T18:48:33ZTobias MalkmusFS#1444 public/protected types in GridView
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 24, 2014 18:48 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecif...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 24, 2014 18:48 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
I'm a little bit puzzled about the public/protected types in the gridview interface.
While type Implementation is protected, maybee should be public in EXPERTIMENTAL_GRID_EXTENSION mode, while type GridViewImp is public.
Both have the same type, so its just a different name ?!?!
https://gitlab.dune-project.org/flyspray/FS/-/issues/1218FS#1218 Add flexible Krylov solvers2013-11-21T14:40:13ZMarkus BlattFS#1218 Add flexible Krylov solvers
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Dec 12, 2012 11:31 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Dec 12, 2012 11:31 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Nov 21, 2013 14:40 |
# Description
The Krylov solvers currently availble in ISTL assume that preconditioners do not change between iterations. But often this is the case (e.g. using AMG with a non-direct solver the number of iterations of the coarse solver might change and therefore the whole AMG changes.)
To allow for changing preconditioners we should add flexible versions to ISTL
https://gitlab.dune-project.org/flyspray/FS/-/issues/1130FS#1130 Write Dune-specific assert which ignores -DNDEBUG2013-11-20T07:31:41ZChristoph GrüningerFS#1130 Write Dune-specific assert which ignores -DNDEBUG
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 15, 2012 09:59 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 15, 2012 09:59 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Nov 20, 2013 07:31 |
# Description
Citing from Jö's message [1]:
That means we want to run many of the tests once with -DNDEBUG
and once with -UNDEBUG. In both cases we want to always enable those misused
asserts in the testing code. We could do that in the following way:
- introduce a macro unittest_assert() which is always enabled and use that in
the relevant testing code. Or use "if(!...) abort();" or similar.
- when compiling with -DENABLE_DEBUG forcibly undefine NDEBUG in the test
programs
- when compiling with -DDISABLE_DEBUG forcibly define NDEBUG in the test
programs
- otherwise, leave NDEBUG untouched.
We can put that stuff in a header. But we should use seperate headers for
unittest_assert() and the NDEBUG-fiddling, since the latter needs a very
specific position in the list of includes.
Are all corner-cases covered by this scheme?
[1] http://lists.dune-project.org/pipermail/dune/2012-June/011537.html
https://gitlab.dune-project.org/flyspray/FS/-/issues/1389FS#1389 Multicomponent vtk data should be written as scalar2013-11-14T13:34:27ZCarsten Gräsergraeser@math.fau.deFS#1389 Multicomponent vtk data should be written as scalar
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 14, 2013 13:34 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating Syst...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 14, 2013 13:34 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Multicomponent point data for paraview is written as 'vector' data with the desired number of components. In case numberOfComponents!=3 loading such data in paraview results in permanent warnings. According to the following paraview bug-report this can be avoided by using the 'scalar' type with the desired number of components instead:
http://paraview.org/Bug/bug_relationship_graph.php?bug_id=12024&graph=relation
If 'vectors' is replaced by 'scalars' in the .vtu file paraview does indeed not complain any more. As this report is not commented and I could not find appropriate documentation it's unclear if this is a paraview bug or if we misuse the 'vector' type.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1377FS#1377 Add support for MPI_Init_thread2013-10-14T07:32:00ZChristian EngwerFS#1377 Add support for MPI_Init_thread
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Oct 14, 2013 07:32 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Oct 14, 2013 07:32 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
see http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Init_thread.html
The problem is that running MPI with MPI_Init is not thread-safe. The current MPIHelper does not support any thread safe initialization...
https://gitlab.dune-project.org/flyspray/FS/-/issues/1374FS#1374 Raviart-Thomas elements on simplices lack orientation in interface2013-10-08T07:12:14ZChristoph GrüningerFS#1374 Raviart-Thomas elements on simplices lack orientation in interface
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 07:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 07:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The generic Raviart-Thomas elements on simplices lack orientation (called set number s in the documentation) in the interface. This is needed to detected twisted elements. According to Andreas Dedner this data are internally known but not accessible in the interface. Maybe the way twists will be handled, as discussed in Aachen, will help to clarify the interface.
Unless this is done, I revert the deprecation of raviartthomas02d.hh and raviartthomas12d.hh.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1369FS#1369 Add id( intersection )2013-10-01T05:46:54ZMartin NolteFS#1369 Add id( intersection )
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 1, 2013 05:46 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 1, 2013 05:46 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
IdSets assign some orderable, unique identifier to all entities in the grid. As a first step towards making intersections first class citizens in dune, I suggest to assign ids to intersections.
This also has an impact on the boundarySegmentIndex discussion. As indices, they will not be valid during load balancing and users need some way of storing their data during this period. While boundary segments must coincide with a codim-1 entity (except for the periodic case in AlbertaGrid, ALUGrid, and SPGrid), I think this is the cleaner approach.
For most grids, intersections will coincide with some entity in the grid, so this interface addition should not be too much work (except maybe for UGGrid).
https://gitlab.dune-project.org/flyspray/FS/-/issues/1348FS#1348 slow convergence monitors in istl iterative solvers2013-09-05T14:05:42ZFlyspray ImporterFS#1348 slow convergence monitors in istl iterative solvers
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Arne Morten Kvarving (arne.morten.kvarving@sintef.no) |
| Reported at | Sep 5, 2013 14:05 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System | U...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Arne Morten Kvarving (arne.morten.kvarving@sintef.no) |
| Reported at | Sep 5, 2013 14:05 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
I am in need of a mechanism to detect and handle slow convergence in the ISTL iterative solvers.
just to give an idea of how it could look; throw an exception after k iterations with ratio > alpha, for given k and alpha.
usage scenario: my users cannot be expected to have much know-how about linear solvers. i have an expensive preconditioner which should only be used when necessary (extremely anisotrophic grids). i have heuristics to try to choose one, but i don't want to make these too conservative. thus, sometimes the wrong preconditioner is selected. i need to be able to detect this, and rerun with the expensive one without user interaction.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1333FS#1333 ISTL GMRES parallel performance bug2013-08-20T19:31:31ZTobias MalkmusFS#1333 ISTL GMRES parallel performance bug
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Aug 20, 2013 19:31 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecif...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Aug 20, 2013 19:31 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
In parallel, the ISTL GMRES implementation calls in each iteration step_sp.dot( ... ) for each Krylov-basisvector, which is at most "number of Restarts"-times.
Usually, a global summation over each process is called in each _sp.dot( ... ) evaluation.
This makes at most "number of Restarts" + 3 numbers of global communication per iteration.
In my personal code the parallel performance breaks down for more than 2 processes.
At the moment i don't have an example for the performance break down.
I will try to provide one tomorrow.
Best Tobias
https://gitlab.dune-project.org/flyspray/FS/-/issues/1280FS#1280 segfault if accessing empty rows in BCRSMatrix2013-04-10T11:47:08ZFlyspray ImporterFS#1280 segfault if accessing empty rows in BCRSMatrix
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Buhr (andreas@andreasbuhr.de) |
| Reported at | Apr 10, 2013 11:47 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Buhr (andreas@andreasbuhr.de) |
| Reported at | Apr 10, 2013 11:47 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
When accessing elements in a BCRSMatrix in a row which does not contain any entry, you get a segfault. It would be nicer to throw an exception in this case. I propose to apply this diff.
# Attachments
* [add_checking_for_empty_base_array.diff](/uploads/0cf654b17c25164dfe007622f0207fcb/add_checking_for_empty_base_array.diff)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1262FS#1262 StructuredGridFactory<ALU[Any]Grid<3,3> >::create[Any]Grid(...) segfa...2013-03-01T16:26:48ZFlyspray ImporterFS#1262 StructuredGridFactory<ALU[Any]Grid<3,3> >::create[Any]Grid(...) segfaults
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Uli Sack (usack@math.fu-berlin.de) |
| Reported at | Mar 1, 2013 16:26 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Linu...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Uli Sack (usack@math.fu-berlin.de) |
| Reported at | Mar 1, 2013 16:26 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Linux 64bit |
# Description
The attached file triggers the problem.
# Attachments
* [structuredgridfactory_alu3_test.cc](/uploads/7cf41a4498295b7dcbf01575403c7b9a/structuredgridfactory_alu3_test.cc)
https://gitlab.dune-project.org/flyspray/FS/-/issues/796FS#796 graphRepartition segfaults for partial index sets2012-10-05T14:54:11ZMarkus BlattFS#796 graphRepartition segfaults for partial index sets
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Jun 6, 2010 08:10 |
| Type | Bug Report |
| Version | 1.2 |
| Operating System | Unspecified / All |
| Last...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Jun 6, 2010 08:10 |
| Type | Bug Report |
| Version | 1.2 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Oct 5, 2012 14:54 |
# Description
Triggered e.g. with "dnaplfv 4 1 30" in pdelab-howto (-r 532) when using AMG with 32 processes.
It seems like it happens somewhere in fillIndexSetHoles. Further investigation is needed but currently time is lacking.
Meanwhile the bug is circumvented by setting up complete index sets (one index for every unknown).
https://gitlab.dune-project.org/flyspray/FS/-/issues/1175FS#1175 insertionIndex methods are not tested2012-09-01T15:26:38ZOliver Sanderoliver.sander@tu-dresden.deFS#1175 insertionIndex methods are not tested
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 1, 2012 15:26 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / Al...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 1, 2012 15:26 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
We require the GridFactory class implementations to provide insertionIndex methods. Apparently there is no test for them. Hence grid implementations may fail to implement these methods without anyone noticing.
https://gitlab.dune-project.org/flyspray/FS/-/issues/975FS#975 outerNormal for outside entity2012-07-10T18:45:28ZAndreas DednerFS#975 outerNormal for outside entity
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 22:43 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified /...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 22:43 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jul 10, 2012 18:45 |
# Description
For surface grids one in general does not have matching outerNormals, e.g.,
N_{T'} != -N_T
where T and T' are neighboring elements.
On an intersection one now needs to find the corresponding intersection on outside to obtain n_{T'} through iteration over all intersection and some matching. That is quite difficult and expensive especially if the normals are not constant.
Suggestions (with increasing complexity for everyone):
A: add outerNormalInOutside(x) to intersection
B: implement some sort of reverseIntersection
method on the Intersection class which provides the matching intersection from the outside entity.
C: Have method to obtain normal on the entity:
outerNormal(i,x) (x in codim=1 or codim<0> coordinates).
One could then use something like:
inter.outside()->outerNormal(inter.numberInOutside, inter.geometryInOutisde.global(x))
D: have the intersection provide an insideIntersection() and outsideIntersection() method returning a class with methods like geometry() (the same as geometryInInside/Outside) and so on. Code like (*iter).geometryInInsde(x) would then have to be changed to (*iter).insideIntersection().geometry(x). The Intersection class would then have the bool methods (neighbor/boundary...) and the geometry method while all other methods would be moved to the class returned by insideIntersection() and outsideIntersection()
Because I think D would be too intrusive and not worth it, I favor A or B.
But perhaps somebody has a better suggestion?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1105FS#1105 Point-to-point communication wrapper for MPI missing.2012-06-07T09:39:48ZRobert KFS#1105 Point-to-point communication wrapper for MPI missing.
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:21 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| La...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:21 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jun 7, 2012 09:39 |
# Description
Currently, in dune-common we only have collective communication, but no point-to-point communication such send and receive (i.e. MPI_Isend, MPI_Irecv) is available.
The communication classes should be improved providing such features.
Together with that we need a proper stream class (e.g. like the ALUGrid ObjectStream currently used as message buffer in gather and scatter of the DataHandle) allowing to read/write simple objects to/from the data stream which then can be exchanged as MPI_BYTE stream.
https://gitlab.dune-project.org/flyspray/FS/-/issues/942FS#942 Nonconforming information on Intersections not sufficient. 2012-06-07T09:39:13ZRobert KFS#942 Nonconforming information on Intersections not sufficient.
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Jul 21, 2011 15:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Uns...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Jul 21, 2011 15:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jun 7, 2012 09:39 |
# Description
The method conforming on intersections does not deliver enough information. One would also like to know whether the inside or the outside entity has a non-conforming face. Currently this cannot or only in an expensive way be determined.
I suggest to add a new method nonConforming that returns the level of non-conformity, conforming = 0,
insideConforming > 0
outsideConforming < 0
By using nonConforming () == 0 one can implement the old method conforming().