 30 Aug, 2017 1 commit


Ansgar Burchardt authored

 29 Aug, 2017 2 commits


Ansgar Burchardt authored

Ansgar Burchardt authored

 19 Jul, 2017 2 commits


Ansgar Burchardt authored
MCMGMapper: use new layout function objects with DUNE 2.6 See merge request !19

Ansgar Burchardt authored

 17 Jul, 2017 2 commits


Ansgar Burchardt authored
add missing `#include <dune/common/stdstreams.hh>` See merge request !18

Ansgar Burchardt authored
It is required for the `dinfo` stream.

 14 Jun, 2017 1 commit


Ansgar Burchardt authored

 15 May, 2017 2 commits


Ansgar Burchardt authored
Remove unused class MultiVector See merge request !17

Jonathan Youett authored

 14 Feb, 2017 5 commits


Oliver Sander authored
Silence compiler warnings See merge request !16

Jonathan Youett authored

Jonathan Youett authored
The intersection of edges is already handled by the forward and inverse projection of the edge corners. If parallel edges are not skipped this might lead to degenerate remote intersections.

Jonathan Youett authored
This fixes the gridglue.size() method and also the iterators if the projection is empty

Jonathan Youett authored

 13 Feb, 2017 1 commit


Jonathan Youett authored
In contact problems both projections are commonly used. For the outer normal projection the projection is done along the outer normals of the grid1. The closest point projection is done along the outer normal of grid2, due to the projection being a best approximation. Hence both projections can be implemented via a simple switch of ordering.

 16 Dec, 2016 3 commits


Ansgar Burchardt authored
Revert "Merge branch 'rework/contactmerge_switch_projection' into 'master'" This reverts merge request !9 I would like to make a few changes before merging this. I recently figured out that the change rather corresponds to a discretisation/implementation of the closest point projection than the normal projection. Hence, I want to add a flag to allow switching between the forward normal and the closest point projection. See merge request !11

Jonathan Youett authored
This reverts merge request !9

Ansgar Burchardt authored
Switch the order of grid1 and grid2 before projecting the faces This switch has the advantage that the inverse projection is now unique on the grid1 side (formerly it was only the case on the grid2 side). In the mortar discretisation one integrates over the grid1 side and nonunique inverse projected corners lead to wrong contact constraints. See merge request !9

 06 Dec, 2016 6 commits


Ansgar Burchardt authored
The parallel version of UG doesn't support having more than one grid.

Ansgar Burchardt authored

Ansgar Burchardt authored

Ansgar Burchardt authored

Ansgar Burchardt authored

Ansgar Burchardt authored

 05 Dec, 2016 1 commit


Ansgar Burchardt authored

 10 Jun, 2016 1 commit


Jonathan Youett authored
This switch has the advantage that the inverse projection is now unique on the grid1 side (formerly it was only the case on the grid2 side). In the mortar discretisation one integrates over the grid1 side and nonunique inverse projected corners lead to wrong contact constraints.

 04 May, 2016 2 commits


Ansgar Burchardt authored
Stabilise contactmerge I still run into problems using the new implementation within `ContactMerge`. I added a new test example to `projectiontest.cc` where a wrong edge intersection is found, which leads `StandardMerge` to stop running properly. The problem in this test case (where both triangles are almost _orthogonal_ to each other) is the following: One vertex is forward projected in the negative projection direction, and hence dismissed. Still, the inverse projection and edge intersection is performed using the forward projected triangle (where one of the vertices is projected in the wrong direction). While in this test case all inverse projected vertices are correctly dismissed, one edge intersection is falsely accepted. I also ran into similar problems, where all inverse projected vertices were false accepted, which all originate from one or more _wrong forward projected_ vertices. The fix that I use in my code is to declare a projection _invalid_ whenever the forward projection is too far in the wrong direction. This fix on the one hand provides a much better performance of the advancing front algorithm but on the other hand also prevents one intersection case that might be desired: When the forward projection is negative because of an overlap of the grids, there can still be valid inverse projections/edge intersections. To allow this case in a certain amount, the projection is only declared _invalid_ if the negative projection is larger than `2*allowedOverlap` (or some other number). An example for this is given in the `projectiontest.cc>test_project_overlap` See merge request !6

Ansgar Burchardt authored
This help with checking that a ContactMerge mapping is injective. Note that it currently only works for Codim1 mergers on grids that also provide Codim1 iterators (one can wrap other grids in a GeometryGrid which always provides Codim1 iterators).

 26 Apr, 2016 1 commit


Ansgar Burchardt authored
Requestedby: Jonathan Youett <youett@mi.fuberlin.de>

 30 Mar, 2016 2 commits


Ansgar Burchardt authored

Ansgar Burchardt authored
Triangulate intersection polygons using the first node as anchor point This avoids the insertion of an artificial center of mass point and leads to less remote intersections See merge request !8

 22 Mar, 2016 1 commit


Jonathan Youett authored
This avoids the insertion of an artificial center of mass point and leads to less remote intersections

 17 Mar, 2016 1 commit


Jonathan Youett authored
When the forward projection of a vertex is too much in the wrong direction the whole projection should be declared invalid to avoid artificial inverse projections and edge intersections. The order of the tolerance must be of the order of the mesh size rather than the allowed overlap to ensure that desired intersections of almost penetrating surfaces are not dismissed

 16 Mar, 2016 5 commits


Ansgar Burchardt authored
Also print the success of the projection Also print the success of the projection in the method `print(Projection)` See merge request !7

Jonathan Youett authored

Jonathan Youett authored

Jonathan Youett authored
If the forward projection of a vertex can only be achieved by projecting in the wrong projection direction, the forward projected triangle should not be used for an inverse projection or edge intersection, as the results are usually wrong. One exception is the case of initially penetrating grids, where one might still want to keep the resulting intersection. For this case the projection is dismissed if the forward projection is further (in the wrong direction) than two times the allowed overlap.

Jonathan Youett authored

 15 Mar, 2016 1 commit


Ansgar Burchardt authored
MultiLinearGeometry should now be defined on all vertices.
