dolfin team mailing list archive

[Chris Greene <archgoon@xxxxxxxxx>]

Hi Andre,

Thank you very much, I'll write a temp function to handle my situation for
the present (as my problem is a *bit* easier than the general,
multi-dimensional, multiple cells case ;) ). I'm writing a Monte-Carlo
simulation with random electron trajectories (which can be thought of as a
sequence of line segments), and the cells each have an associated electric
field and scattering rates. I need to know how much time (and where) an
electron spends in which cells to properly calculate the scattering and
drift. What I plan on doing at this point is finding which cells are
intersected with, and then find out the intersection points on those cells
to determine the intersection length. So I need both which cells of the mesh
are intersected by the line and the "area" of intersection for each cell. If
I had several lines forming a 1D mesh, I would also need to know which lines
intersected with which cells.

Thanks,
Chris Greene

>
> Message: 1
> Date: Mon, 17 Aug 2009 20:45:28 +0200
> From: Andre Massing <massing@xxxxxxxxx>
> Subject: Re: [DOLFIN-dev] Expansion of IntersectionDetector
> To: dolfin-dev@xxxxxxxxxx
> Message-ID: <200908172045.28891.massing@xxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-15"
>
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www.fenics.org/pipermail/dolfin-dev/attachments/20090817/1321505f/attachment-0001.htm
>
>
>