← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Implement algorithm for checking if a mesh is correctly ordered,

 

On Fri, Nov 14, 2008 at 02:03:23PM +0100, Anders Logg wrote:
> On Fri, Nov 14, 2008 at 12:56:56PM +0000, Garth N. Wells wrote:
> > 
> > 
> > Anders Logg wrote:
> > > On Fri, Nov 14, 2008 at 09:33:31AM +0000, Garth N. Wells wrote:
> > >> DOLFIN wrote:
> > >>> One or more new changesets pushed to the primary dolfin repository.
> > >>> A short summary of the last three changesets is included below.
> > >>>
> > >>> changeset:   5153:d2f703ef98b0798fef534e587d95cfcb6374dfc1
> > >>> tag:         tip
> > >>> user:        Anders Logg <logg@xxxxxxxxx>
> > >>> date:        Fri Nov 14 09:22:22 2008 +0100
> > >>> files:       ChangeLog SConstruct demo/fem/simple/cpp/main.cpp demo/fem/simple/tetrahedron.xml.gz demo/function/eval/cpp/main.cpp demo/pde/bcs/cpp/main.cpp demo/pde/elasticity/cpp/main.cpp demo/pde/stokes/stabilized/cpp/main.cpp demo/pde/stokes/taylor-hood/cpp/main.cpp dolfin/io/PXMLMesh.cpp dolfin/io/XMLMesh.cpp dolfin/mesh/Box.cpp dolfin/mesh/Cell.h dolfin/mesh/CellType.cpp dolfin/mesh/CellType.h dolfin/mesh/DynamicMeshEditor.cpp dolfin/mesh/DynamicMeshEditor.h dolfin/mesh/Interval.cpp dolfin/mesh/IntervalCell.cpp dolfin/mesh/IntervalCell.h dolfin/mesh/Mesh.cpp dolfin/mesh/Mesh.h dolfin/mesh/MeshEditor.cpp dolfin/mesh/MeshEditor.h dolfin/mesh/MeshOrdering.cpp dolfin/mesh/MeshOrdering.h dolfin/mesh/PointCell.cpp dolfin/mesh/PointCell.h dolfin/mesh/Rectangle.cpp dolfin/mesh/TetrahedronCell.cpp dolfin/mesh/TetrahedronCell.h dolfin/mesh/TopologyComputation.cpp dolfin/mesh/TriangleCell.cpp dolfin/mesh/TriangleCell.h dolfin/mesh/UnitCircle.cpp dolfin/mesh/UnitCube.cpp dolfin/
> > me
> > >> sh/UnitInterval.cpp dolfin/mesh/UnitSphere.cpp dolfin/mesh/UnitSquare.cpp
> > >>> description:
> > >>> Implement algorithm for checking if a mesh is correctly ordered,
> > >>> same algorithm for all cell types. CellType::order() should be
> > >>> reimplemented similarly. Also removed call to order() in all demos.
> > >>> There are still some issues that need to be sorted out, and we may
> > >>> need to do some mnemonics so we don't need to check the ordering
> > >>> more than once.
> > >>>
> > >>
> > >> This has broken some unit tests and demos. It would be good if 
> > >> developers run test.py regularly so we aren't going backwards in terms 
> > >> of getting things working again.
> > >>
> > >> Garth
> > > 
> > > Yes, I know but I made an exception.
> > > 
> > 
> > Is it easy to fix the bug that breaks k > 1 elements? The problem is 
> > that a 'const Mesh' object is being modified inside DofMap::init().
> > 
> > Garth
> 
> I will take a look.

How about this:

1. When we compute new connectivity (init), we first check that the
mesh is ordered and otherwise give an error.

All the meshes we have now in data/meshes and all built-in meshes are
ordered, and there is also a script dolfin-order that can do this for
external meshes. It's good to be explicit about us requiring ordered
meshes instead of quietly reordering them which can lead to difficult
to find bugs.

2. When the connectivity has been computed, the mesh is ordered.

This would guarantee that the init() function does not mess with any
preexisting connectivity (by 1) and that all connectivity that comes
out is ordered (by 2).

This means that we may keep the const_cast in init() with good
conscience since we never change the mesh, only compute connectivity
which is already there (but has not yet been generated). It also
guarantees (I think) that for example edges are always generated with
the same numbering.

-- 
Anders

Attachment: signature.asc
Description: Digital signature


References