dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

Hi Chris,

On Monday 17 August 2009 20:04:47 Chris Greene wrote:
> Currently IntersectionDetector returns only the cell indices of the
> intersection of two meshes. It is desirable for some applications, perhaps
> with a codimension parameter, to return a new mesh object that would be the
> actual intersection. 

I am exactly working on this issue right now by using the CGAL library:) In  
the first run the goal is to provide the some extended functionality, i.e.
for a given mesh and another containter of geometric primitives ( e.g. list of 
3d triangles, segments or in particular another mesh) to provide functions for
1. Computing an intersection map, mapping corresponding ids to each other, for 
instance which cell of mesh1 is intersected by which cells of mesh2
2. Compute the actual intersection objects mapped to corresponding ids (later 
be used for computing artifical interfaces and suchlike).

ATM we are right in the design and implementation process, but it should be 
soon available (hopefully only a few weeks) :)

Return a mesh object as an outcome of the computations would not be trivial, 
since generally the intersection region might be quite complex (collection of 
scattered polygons, polyhedrons, probably not as simple as triangles), so a 
mesh generation process would be needed. The resulting intersection might even 
be a complex with degenerate primitives.  

> For my particular application it would be useful to
> have thr line segment intersection (or at least the points) of a line
> passing through a tetrahedron. 

I am a bit curious :) what will this be exactly for? I am asking, since I am 
still in the design process and interested in possible application. 
So any input by you will be greatly appreciated!
Our starting point was some Nitsche's method for overlapping meshes and the 
hope to apply this to Fluid-Structure-Interaction problems (in the very end 
:))


> Would this be a reasonable extension to the
> Intersection Detector, is it already subsumed by other functionality within
> FEniCS, or perhaps is viewed as outside the scope of the FEniCS project?

Yes it is a resonable extension and yes, it*will* be subsumed by other 
functionality ;)


>
> Chris Greene