1. 30 Aug, 2017 1 commit
  2. 29 Aug, 2017 2 commits
  3. 19 Jul, 2017 2 commits
  4. 17 Jul, 2017 2 commits
  5. 14 Jun, 2017 1 commit
  6. 15 May, 2017 2 commits
  7. 14 Feb, 2017 5 commits
  8. 13 Feb, 2017 1 commit
    • Jonathan Youett's avatar
      Add possibility to switch between closest point and normal projection · f69e978a
      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.
      f69e978a
  9. 16 Dec, 2016 3 commits
    • Ansgar Burchardt's avatar
      Merge branch 'revert-e9d9a333' into 'master' · 875a3fbe
      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
      875a3fbe
    • Jonathan Youett's avatar
      Revert "Merge branch 'rework/contactmerge_switch_projection' into 'master'" · 588cdabb
      Jonathan Youett authored
      This reverts merge request !9
      588cdabb
    • Ansgar Burchardt's avatar
      Merge branch 'rework/contactmerge_switch_projection' into 'master' · e9d9a333
      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
      non-unique inverse projected corners lead to wrong contact constraints.
      
      See merge request !9
      e9d9a333
  10. 06 Dec, 2016 6 commits
  11. 05 Dec, 2016 1 commit
  12. 10 Jun, 2016 1 commit
    • Jonathan Youett's avatar
      Switch the order of grid1 and grid2 before projecting the faces · 014373ef
      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
      non-unique inverse projected corners lead to wrong contact constraints.
      014373ef
  13. 04 May, 2016 2 commits
    • Ansgar Burchardt's avatar
      Merge branch 'stabilise_contactmerge' into 'master' · 5b885d42
      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
      5b885d42
    • Ansgar Burchardt's avatar
      Add new debug utility · 972f713d
      Ansgar Burchardt authored
      This help with checking that a ContactMerge mapping is injective.  Note
      that it currently only works for Codim-1 mergers on grids that also
      provide Codim-1 iterators (one can wrap other grids in a GeometryGrid
      which always provides Codim-1 iterators).
      972f713d
  14. 26 Apr, 2016 1 commit
  15. 30 Mar, 2016 2 commits
  16. 22 Mar, 2016 1 commit
  17. 17 Mar, 2016 1 commit
    • Jonathan Youett's avatar
      Change order of tolerance for dismissing the projection · c17cc327
      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
      c17cc327
  18. 16 Mar, 2016 5 commits
  19. 15 Mar, 2016 1 commit