dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On Mon, Oct 8, 2012 at 9:14 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> On Mon, Oct 8, 2012 at 1:09 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>> On Sun, Oct 07, 2012 at 08:16:33PM +0100, Garth N. Wells wrote:
>>
>>> Is this consistent?
>>
>> I'm not sure, it's just a choice we needed to make. It makes sense
>> that being connected means sharing a common vertex, but this obviously
>> fails for the case (0, 0) so then I thought it made sense for two
>> vertices to be neighbors if they share a cell. For simplices it's the
>> same as sharing an edge, so when quads are now being added we might
>> need to rethink this.
>>

I've made a change in TopologyComputation that I think makes the (0,0)
case somewhat more consistent in that

    for (MeshEntityIterator v(entity, 0); !v.end(); ++v)
    {

    }

will loop over all vertices connected to 'entity'. When entity.dim()
== 0, it is a 'Point' and the connected 'vertex' is the vertex that it
sits on.

All the unit tests pass with this change, and it should allow the
special case handling for d=0 in BoundaryComputation to be removed.

Any objections to this change being pushed to trunk?

Garth


>>> I have a feeling that it's not because I'm having to write a bunch
>>> of special cases to make BoundaryMesh and the mesh partitioning work
>>> in 1D because facets and vertices are of the same topological
>>> dimension.
>>>
>>> Would it work if
>>>
>>>    CellIterator c(cell)
>>>
>>> yielded *c == cell? (and likewise for other topological dimensions)
>>
>> You mean a cell is only neighbor to itself? I think that would break
>> quite a few algorithms currently in DOLFIN that rely on looking at
>> neighboring cells.
>>
>> Did you fix the 1D boundary mesh bug? What was the fix?
>>
>
> The fix/hack was to add special cases to get around the (0, 0)
> connectivity case. It's ugly.
>
> I'll see if the (0, 0) case can be made consistent with the (d, d)
> case - treating a cell as a  'Point cell' that is connected to a
> vertex.
>
> Garth
>
>> --
>> Anders
>>
>>
>>> Garth
>>>
>>> >> In the above case, each cell will be connected to itself and the other
>>> >> cell, so the loop should print only this:
>>> >>
>>> >>   In cell loop
>>> >>   In cell loop
>>> >>
>>> >> Why do you get 6? I tried this (in Python) and get only 2.
>>> >>
>>> >
>>> > Sorry, try
>>> >
>>> >      UnitSquare mesh(2, 2);
>>> >
>>> > I used mesh(1, 1) in testing, and indeed in only prints twice.
>>> >
>>> >>> In what sense are entities of the same dimension 'connected'? The
>>> >>> present behaviour is causing a problem when computing a BoundaryMesh
>>> >>> in 1D because it picks up the end vertices, but then iterates along
>>> >>> the lines of
>>> >>>
>>> >>>         for (VertexIterator v(vertex); !v.end(); ++v)
>>> >>>         {
>>> >>>
>>> >>>         }
>>> >>>
>>> >>> which then yields the vertex that is one place in from the boundary.
>>> >>
>>> >> The algorithm for BoundaryMesh is to iterate over all facets of the
>>> >> mesh, in this case all vertices, and then check for each one if it is
>>> >> connected to exactly one entity of dimension D (cells) which in this
>>> >> case is edges (intervals). So something clearly goes wrong in
>>> >> TopologyComputation in 1D.
>>> >>
>>> >> I'll look at it later.
>>> >>
>>> >
>>> > The problem is what I describe above with the iterators over the (d,
>>> > d) connectivity with d=0. The BoundaryMesh code finds a facet on the
>>> > boiundary (vertex in the case of 1D), and then iterates over the
>>> > vertices of the facet:
>>> >
>>> >      for (VertexIterator v(facet); !v.end(); ++v)
>>> >      {
>>> >
>>> >      }
>>> >
>>> > When facet is not a vertex, this computes all the vertices that lie on
>>> > the boundary. When facet is a vertex, the above returns vertices that
>>> > share the cell with facet, but which do not lie on the boundary.
>>> >
>>> >
>>> > Garth
>>> >