[Gmsh] Gmsh and postprocessing
oshima at eng.niigata-u.ac.jp
Fri Dec 7 01:45:35 CET 2007
As myself being the author of a collection of a modification patch and
tools to Gmsh that is meant to support OpenFOAM mesh/field file
format, which I call it gmshFoam
(http://openfoamwiki.net/index.php/Contrib_gmshFoam), I think I can
provide some suggestions to your questions:
From: "Martin Vymazal" <martin.vymazal at vki.ac.be>
Subject: [Gmsh] Gmsh and postprocessing
Date: Thu, 6 Dec 2007 12:09:25 +0100 (CET)
> Hi all,
> I'm currently a student at the von Karman Institute for Fluid Dynamics in
> Belgium and I'm supposed to incorporate a gmsh writer into COOLFluid, a
> numerical software package being developed here at the institute (if
> you're interested, visit http://coolfluidsrv.vki.ac.be/coolfluid). For
> the start, I would like to have an output of a simulation on second order
> triangles that I could postprocess using gmsh. I have a couple of
> questions concerning the file formats used by gmsh.
> First, it seems like the description of mesh geometry (nodal
> coordinates, elements, etc.) and the output data (i.e. the result of my
> simulation) have to be kept in separate files. Is there a way to have
> these data in a single file ? Since the datasets may be possibly quite
> large, I'm interested in the version 2.0 ascii or binary formats, not
> the old format.
> Second, if I understand it correctly, there can be stored 1,3 or 9
> values per node in a *.pos file (if I use scalar, vector or tensor
> triangles). However, if you consider 2D compressible Euler simulation,
> for example, you will have 5 values per node (density,2 velocity
> components, pressure, energy). Is it possible to store other number of
> solution values per node that 1/3/9 ? Maybe there's a way to use
> user-defined datastructures ?
I think basically you can do what you intend to do, provided you
carefully consider the followings.
* I recommend you use the binary postprocessing format described in
Section 9.2.3 of the reference manual (
http://www.geuz.org/gmsh/doc/texinfo/gmsh_10.html#SEC70 ). If your
simulation can get moderately large this is the only feasible format
(the text format is too slow to handle).
* Separate postprocessing views to have one variable (density,
velociy, pressure, energy) per postprocessing view. I think for
2D-vectors setting the z components to 0 should typically be fine.
* Although you can pack all the postprocessing views in one single
file simply by concatenating $View-$EndView sections of all the
variables, I'd recommend you make your writer to write one variable
per file. Since Gmsh handles all the view data on memory you can
easily eat up all the available memory if you load all the variables
> I was also looking for some example files
> at gmsh wiki, but most of them are the 'mesh' files, not postprocessing
> ones. Maybe it would be useful to upload some, if anybody is willing to
> share them.
> I tried to find the answers to my questions in the documentation and in
> the forum, but I'm new to gmsh. I apologize for bothering you if the
> answer can be found easily, maybe I overlooked something.
> I also know that the priority of gmsh is meshing, not visualization. If
> you know about any other (free) alternatives that allow the user to
> display curvilinear (2nd or possibly higher order) elements, I'd be
> happy to hear about them. Thank you for your reply.
In my opinion the weakest point in Gmsh as postprocessor is, as
written in the reference manual, that it is not suited for large cases
(e.g. a case with > 1 million elements and some hundered
timesteps). You might want to also consider other postprocessors if
you plan to handle such cases. Reading through the VTK format
documentation ( http://www.vtk.org/pdf/file-formats.pdf ) it seems VTK
(and VTK-based postprocessors) has quadratic elment support (I have no
experience with the format though).
> Martin Vymazal
> gmsh mailing list
> gmsh at geuz.org
Hope this helps,