dolfin team mailing list archive

[jhoffman@xxxxxxxxxxx]

>> This should work. Maybe there should be a more general name than
>> boundary,
>> since it may in fact does not have to be part of the physical boundary?
>> On
>> the other hand we do not want the name to connect to the dimension of
>> the
>> object either (such as "surface" for example); "subdomain", "subset", or
>> "manifold" might work?
>
> Perhaps, but it's natural to work with boundaries when specifying
> boundary conditions. The standard case is that boundary conditions are
> really specified on boundaries, and if someone wants to specify
> boundary conditions on some other part of the domain that may be fine
> but it's still called a boundary.
>
> Another point may be that we should have Domain and Boundary, not Mesh
> and Boundary. On the other hand, Mesh is probably the right concept
> since it is really a mesh (a collection of mesh entities) rather than
> a Domain. Perhaps we will need Domain at a later point, and then one
> could create a Mesh from a Domain, and a Mesh might as well be a mesh
> created from a Boundary:
>
> Domain domain(...);
> Mesh mesh(domain);
>
> Domain domain(...);
> Boundary boundary(domain);
> Mesh mesh(boundary);
>

Ok. So maybe we should stick to Mesh then, and only indicate the nature of
the mesh in the name of the object. And maybe there should be some
function returning the (space) dimension of the mesh, if we want to
distinguish between a surface mesh and a curve mesh for example.

Domain domain(...);
Mesh volume_mesh(domain);

Boundary boundary(domain);
Mesh surface_mesh(boundary);

But there are also other differences. In the Boundary class we do not
today have the concept of a "cell", so there is a difference between a 2d
triangular "volume" mesh, and a 2d (surface) boundary mesh of a 3d domain.

/Johan