dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #26105
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