I have been compiling openflower in Windows platform and everything went ok.
I also introduced another file format, other than gmsh. I think most routines are gmsh specific. I think that openflower should establish its own mesh format as simple as possible. I think that it the program should not admit that there are surface elements in the mesh and that boundary conditions are assigned to surface elements. The surface elements should be built using the 3D elements.
For instance, I tried importing a mesh model only with a list of nodes and a list tetrahedrons. Everything went ok but when checking double faces the message appeared:
"Problem in octree: possibly two identical faces in two different leafs..."
"Send bug report at http://sourceforge.net/projects/openflower".
I would like openflower to define a specification for the files used in openflower and not be tied to any pre/post processing application. This way each person could build there own translators.
For the mesh file format, I would suggest something like:
$COM // Comments
2 // Number of comments
230 // Number of nodes
0 0 0
1 1.23 1
2 3.23 3
2 // Number of beam elements
34 //Number of triangles
2 3 1
The same for quadrangles - $QUAD
The same for tetrahedrons - $TETRA
The same for hexahedron or bricks - $HEXA
The same for prism or wedges - $PRISM
The same for pyramid - $PYRAM
I agree that it would be better to interface to an open file format, rather than to a specific code.
But aren't there open standards already defined for describing a mesh? I don't know for sure, but I would be quite surprised if there weren't, since meshes are used for lots of scientific applications. There might even be some that come with open source wrapper classes that do all the mundane stuff like hooking up the pointers.
PS: great news that openFlower compiles on Windows, by the way. good on ya, x-flow, for giving it a shot and posting the result.
I think that a topic about data formats should be included in the Reference Manual.
- Input file format (containing all the parameters and name of the files like *.flw),
- Mesh file format (like *.msh),
- BC file format,
- Results file format (this could be defined later on).
I believe there is no "standard" format for the mesh. But I do know that some meshers only provide lists of nodes and elements, with no information about the surface the element belongs to. In gmsh we apply boundary conditions to surfaces. However, if we would import data from another mesher we would possibly not have information about the surface boundary and so on.
I have found the cause of the error described above. In function:
there is a comment:
// For each node, we find the two corresponding double faces
This is true if you have solid and surface (boundary) elements. If you only have solid elements (which is the most frequent case when you use volume meshing) you need to generate these surface elements first. I gues gmsh always generates a surface mesh and then a solid mesh but some meshers only generate this information "internally" and export only the solid elements.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.