dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Oct 26, 2008 at 12:12:06PM +0000, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Sun, Oct 26, 2008 at 12:50:12PM +0100, 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:   5003:f2effd253de3ae72894bdecb768447b8336a5014
> >> tag:         tip
> >> user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
> >> date:        Sun Oct 26 11:50:01 2008 +0000
> >> files:       dolfin/ale/HarmonicSmoothing.cpp dolfin/mf/MatrixFactory.cpp
> >> description:
> >> DOLFIN compiles again!
> > 
> > Nice!
> >
> 
> We need to have a good look at const in the mesh classes. I used quite a 
> bit of cont_cast to get things worker because it's always easier to 
> start with something that compiles (and we can continue with the 
> Function interface if it compiles). A few things:

Good. I agree it's best to get it to compile, then try removing all
the const_casts.

> - Do we want to be able to call functions like Mesh::order on const 
> meshes? I would suggest yes because it's nice to make objects like Form 
>   const because they are 95% const, but it is necessary to call various 
> mesh functions. We would need to use mutable where necessary in the mesh 
> classes.

I think the init() functions can very well be const (and use
const_cast internally). One may say that for example the edges of a
Mesh always exist, even though that may not have been computed. So,
one should be able to do

  const Mesh& mesh;
  for (EdgeIterator edge(mesh); !edge.end(); ++edge)
  {

  }

even if this may potentially lead to a precomputation of all edges at the
start of the loop.

However, I don't think it's a good idea to make Mesh::order() const,
since it may potentially change the numbering of the mesh. So a user
could then assemble over a mesh and as a result the mesh will have
changed, even though the assemble() function promises to be const
regarding the Mesh (Form).

This is problematic considering we now automatically initialiaze
edges, faces etc and make sure they are ordered. What I think we need
to do is to check whether or not the mesh is ordered and if not so
give an error message saying that the mesh has not been correctly
ordered. In those cases, a user will need to do

  mesh.order()

and then call assemble().

> - We should add cont version of the various mesh iterators.

Do we need that? My idea with the mesh iterators (now) was that they
are always const in the sense that they can be created from a const
Mesh or MeshEntity. This means that one cannot use an iterator to
modify the mesh. The only place I can think of where this makes sense
(except perhaps internally in TopologyComputation) is to change
coordinates, and in that case we can require that one uses
mesh.geometry().

-- 
Anders

Attachment: signature.asc
Description: Digital signature