[Gmsh] Gmsh and postprocessing

Fri Dec 7 22:09:26 CET 2007

Hi Martin - I second Takuya's remarks.

*However* we've made big changes in the code to address precisely these 
issues. If you check out the latest experimental versions available on 
the web site, you will see that the post-processor is actually brand 
new: it has been completely rewritten, and shares almost no code with 
Gmsh <= 2.0.8.

At the moment, from the outside, nothing seems to have changed. This is 
on purpose: we've actually worked really hard to maintain 100% backward 
compatibility with the old formats and options. But the new architecture 
will allow us to have datasets defined on standard meshes (for example 
with data shared on nodes, hugely reducing the size for continuous 
datasets), datasets processed in-place (without loading everything in 
memory), etc.

To benefit from this new architecture, though, we now need to define new 
input/output formats. One simple idea would be to append post-processing 
views (ascii or binary) to .msh files, reusing all the topological 
information from the meshes.

Do you have any other ideas/formats we should consider ? (The VTK 
formats for example seem pretty nice.)

Christophe

OSHIMA Takuya wrote:
> Hi Martin,
> 
> 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
>   at once.
> 
>> 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
>> http://www.geuz.org/mailman/listinfo/gmsh
> 
> Hope this helps,
> Takuya OSHIMA
> 
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
> 
> 

-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine