Is this the situation? Ideally .msh file should get the "boundary surfaces/volume" information.
One way to design (and get totally attached to Gmsh would be to use .geo, .msh, and .bcd files and later mark the necessary information on the cell nodes.
How do we handle the case where our Geometry comes from Industry - STEP file for example. Gmsh (with OCC support) would give us an unstructured mesh. How do we assign which "surface" is "Inlet / Outlet / Wall"?
BTW choosing Gmsh as the pre and post processor was a very good design. Geometry creation is so easy with Gmsh. It has a very good sketcher(snapping, selection) - not known to the world outside :-) Dumping all the post information into a single file makes it bulky, but with the script files provided by you, things are lot more easy. One more thing, ImageMagicK library is inbuilt with linux (I use Ubuntu), so using "convert" command on the shell can easily generate an animated gif from images (png, jpg, gif etc). It is as flexible as the "whirlgif". Thanks for helping the open source community to reach this far.
Ok - This question was _NOT_ strictly related to the solver and hence I will add more information (possibly solution).
Gmsh is a great tool on the pre-processing side. The .geo file should _NOT_ be looked as a static data file (like STL), but more like a script. Having said that, there exists an option to _MERGE_ the STEP file and create new physical surface groups inside a .geo file.
I have not tried this option myself with OpenFVM, but seems promising. Finally the question is how does OpenFVM sort out the information internally and applies the boundary conditions on the mesh cells. A little more insight into this would be helpful.
I was developing a graphical pre-processor that would automatically detect surfaces/physical regions based on surface angles. The user could then edit these physical regions and assign BCs.
However, I haven't had too much spare time to finish it.
If you find out a way to this using Gmsh please let me know.
Right from the beginning our approach has been based on VTK for both pre and post. So our natural inclination is towards ParaView. VTK allows a fair amount of control to manipulate the STL geometry as well (many of the pre-processing problems get eliminated automatically).
Since we come from the typical CAD background, our test models are invariably STL's (so we start with an unstructured grid there and there :-)). But getting a cartesian hex mesh that is body-fitting (and water-tight) is mainly possible due to VTK routines.
Thank you very much for giving helping hand all the time. I have one more question (typical hex vs tet mesh - let me ask it as a separate question)
Log in to post a comment.