← Back to team overview

dolfin team mailing list archive

Re: Namespace for CSG primitives

 

2012/11/4 Garth N. Wells <gnw20@xxxxxxxxx>

> On Fri, Nov 2, 2012 at 6:29 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> > The dolfin-csg branch (and the dolfin-plot) branch are getting ready
> > for merge.
> >
>
> Nice.
>
> > Benjamin and Johannes have worked on adding functionality
> > for generating meshes from geometries described by constructive solid
> > geometry (CSG):
> >
> >   geometry = circle*triangle + square - polygon
> >   mesh = Mesh(geometry)
> >
> > Before merging, what are the opinions of where to put the primitives,
> > in which namespace? Normally, we put everything into namespace dolfin,
> > but some of the new primitives may clash with existing classes for
> > mesh generation (UnitSquare etc).
> >
> > To keep things simple, I would like to put everything in namespace
> > dolfin, so the CSG geometries become a natural part of the FEniCS
> > interface, not something one has to import from a separate namespace
> > (dolfin::csg).
> >
> > The new primitives are
> >
> >   Circle     (2D)
> >   Ellipse    (2D)
> >   Rectangle  (2D)
> >   Polygon    (2D)
> >
> >   Sphere     (3D)
> >   Box        (3D)
> >   Cone       (3D)
> >   Cylinder   (3D)
> >
>
> No polyhedron? I added a CGAL-based mesh generation interface a while
> back that supported polyhedra, so I imagine that some of the necessary
> code for creating a polyhedron is already there.
>

Yes, there is a primitive for reading polyhedrons from file. Off-files and
(ascii) stl-files are supported. It uses cgal for parsing off-files.

Benjamin


>
> > Existing mesh classes that the above may clash with are
> >
> >   Interval
> >   Rectangle
> >   UnitCircle
> >   UnitCube
> >   UnitInterval
> >   UnitSphere        --> remove because it has bad quality mesh?
> >   UnitSquare
> >   UnitTetrahedron
> >   UnitTriangle
> >
> > These are mostly prefixed by "Unit" so that may take care of some of
> > the ambiguities.
>
> The prefix may technically remove the ambiguity, but a practical
> ambiguity between 'shapes' and 'meshes' persists,
>
> >One could also argue that we should rename to
> > UnitSquareMesh etc, but it would break compatibility.
> >
> > One option could be to rename mesh classes to UnitSquareMesh,
> > UnitCubeMesh, and keep deprecated (sub)classes UnitSquare, UnitCube
> > indefinitely to keep backwards compatibility.
> >
>
> No point in renaming if the deprecated names are to be kept indefinitely.
>
> > In summary, I would like to add the new classes to namespace dolfin
> > but I'm looking for opinions on how to best handle naming conflicts.
> >
>
> I'm always in favour of a consistent, meaningful interface over a
> sub-optimal interface for the purpose of backward compatibility.
>
> Garth
>
> > --
> > Anders
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>

References