dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Nov 06, 2008 at 10:20:01AM +0000, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Wed, Nov 05, 2008 at 08:17:25AM +0000, Garth N. Wells wrote:
> >>
> >> Anders Logg wrote:
> >>> On Tue, Nov 04, 2008 at 10:49:48PM +0000, Garth N. Wells wrote:
> >>>> Any problem in adding a field to the Mesh xml format that states if the 
> >>>> connectivity has been ordered?
> >>>>
> >>>> Garth
> >>> Isn't it better to just read in the mesh and then call mesh.ordered()?
> >>> That will give the right answer, whereas a flag may have been set
> >>> incorrectly.
> >>>
> >> Well, we'll need to have a very close look at how we read in 
> >> MeshFunctions because the because the position of the mesh.order() call 
> >> can mess things up without producing an error or warning message.
> >>
> >> Garth
> > 
> > Is the problem that mesh.order() will possibly mess up data stored in
> > MeshFunctions? I don't understand why that should happen. The
> > reordering is only performed locally. The global entity indices remain
> > the same.
> > 
> 
> Take a look at the Stokes Taylor-Hood demo. Doing
> 
>    Mesh mesh("../../../../../data/meshes/dolfin-2.xml.gz");
>    MeshFunction<unsigned int> sub_domains(mesh, "../subdomains.xml.gz");
>    mesh.order();
> 
> works as expected, but
> 
>    // Read mesh and sub domain markers
>    Mesh mesh("../../../../../data/meshes/dolfin-2.xml.gz");
>    mesh.order();
>    MeshFunction<unsigned int> sub_domains(mesh, "../subdomains.xml.gz");
> 
> screws up the boundary conditions.
> 
> Garth

Yes, I see. The problem is that when DOLFIN generates edges/faces (in
TopologyComputation) that algorithm will spit out different things
depending on how the mesh that comes in is ordered locally.

I see three options:

1. Figure out a way for a MeshFunction to know that it is screwed up
(checking some kind of signature on the mesh seeing that it has been
changed).

2. Make the computation of entities always generate the same global
numbering independent of the local numbering of the input mesh. Does
anyone have a good idea for a global numbering strategy?

3. Make sure that all meshes/datafiles we have are always ordered (so
we regenerate subdomains.xml.gz from an ordered mesh). So in
particular we should never need to call order() in any of the demos
(if all our built-in meshes and everything in data/meshes is ordered).
This will fix the problem now (and we need to do this anyway) but it
doesn't solve the problem in the long run.

When I think of it, we should probably do all of the above...

-- 
Anders

Attachment: signature.asc
Description: Digital signature