I am not sure if this is the correct forum for my question; if not, feel free to move it to a more appropriate place.
We are developing and maintaining an open-source mesh generation package for CFD simulations (see http://engits.eu/en/engrid). So far we have used triangulated geometries as input for the mesher. For the program to properly respect sharp edges the adjacent geometric surfaces have to be accessible as individual objects.
I have now started to look into using BRL-CAD for geometric modelling (as a full open-source solution) and so far it looks very promising. Since BRL-CAD is open-source I was wondering if its data-structures could be used directly as oposed to exporting to STL and loosing information on the way.
To demonstrate what I have in mind I have prepared two pictures on a public Dropbox folder. The first picture (http://dl.dropbox.com/u/10046114/volume.png) shows a geometry which has been created with BRL-CAD (quarter sphere subtracted from a rectangular block). The second picture(http://dl.dropbox.com/u/10046114/faces.png) shows the set of faces as it is required by our meshing software. In this case the geometry was first converted to an STL file and then subdivided into individual surfaces with Blender.
Any hints on how to achieve this would be welcome. Maybe it would be possible to call certain BRL-CAD functionality directly from our software.
BRL-CAD's data structures can definitely be used directly and is actually one of our main features. Our API is intently designed to be used flexibly for analysis and other CAE purposes including CFD simulations. I don't recall who, but there was a (not open source, iirc) CFD implementation that integrated with BRL-CAD several years ago quite successfully. More recently, BRL-CAD was integrated with a dynamics/shock simulation code where they leveraged BRL-CAD for geometric representation and fast geometry querying.
More specifically, our LIBRT ray tracing library is where most of the analytic functionality and the geometric data structures reside. These pages show a sampling of some of the ways you can hook an application up to our libraries (just a few examples among dozens available): http://brlcad.org/wiki/Developing_applications
That said, the other CFD code I mentioned had to make some changes to their approach in order to accommodate our more generalized implicit representation. Without those changes, they would have attempted to integrate in the same manner as you're suggesting and that's a lot more difficult (though not impossible).
In computer graphics terminology, your second "faces" picture can be seen to indicate an explicit spline-surface parametric boundary representation (BREP/NURBS). The first "volume" picture you displayed, however, is an implicit CSG volume representation where there is no explicit boundary. Routines for converting from CSG form to BREP//NURBS form do not yet exist, but are being worked on later this year. So, to perform that conversion so you have an actual explicit "face" to reference, you'd either have to wait or help write that code or make changes to your CFD approach to not require explicit topology.
The last detail I'll leave you with, however, is that we do have support for representing BREP/NURBS geometry. If you import a model that is already a spline surface model (e.g., with our 3dm-g or step-g importers), they will import as such and you'll have your face/surface references you're seeking from within BRL-CAD.
thanks for your comprehensive answer!
Access to individual surfaces is required for the following reason:
As part of the meshing process nodes are smoothed (moved around) and then projected back onto the surface of the volume we want to mesh. I guess I could simply project using your ray tracing library - seems to be perfect for the case. In order to respect sharp features (feature edges), however, a node needs to be projected onto two different surfaces (e.g. intersection between sphere and cube). If that is not done, you end up with 'rounded' corners. Another reason is that boundary conditions (inflow, outflow, wall, …) are usually defined on the different surfaces.
At the moment we are conducting a feasibility study for a certain parametric approach to CFD. If this is successful we might get funding for further development; should that happen I will have some time to try to understand the BRL-CAD API. For now we will probably stick with our triangulated surface approach; I have an idea on how to automatise (script) an import function for BRL-CAD databases without defining all surfaces by hand.
You hit the idea spot on the nose regarding using the ray tracing library to project nodes, (pressures, tension, particle flow, etc) and sharp features are easily detected using ray tracing. We're a solid volume ray-tracer so you can use the thickness of segments where a ray intersect's a volume along with surface normals on entry and exit to have a well-behaved geometric definition of boundaries as the dynamics calculations propagate.
That said, I completely understand if you are specifically tasked/funded with a particular parametric approach. Should you decide to try and use our BREP/NURBS support (which can also be ray trace queried), an implicit ray-tracing method, or something else altogether, please feel free to ask questions. Analytic codes, library performance, and robustness are where we focus most of our support and development.
I think I have found a feasible approach for now. Using the g-stl converter a model and all primitive solids are exported to STL files. When importing the model into our tool we can then reconstruct the surfaces by computing the distance from the several solids. It seems to work well for a test model. For the future I would like to use the BRL-CAD ray tracing in order to project onto the CAD model; it is not clear to me yet, however, how sharp features can be respected. At the moment a node is iteratively projected onto all adjacent surfaces (see this image for an illustration: http://dl.dropbox.com/u/10046114/projection.png)
Thanks so far,