[Gmsh] Gmsh and postprocessing

[OSHIMA Takuya]

Dear Christophe,

I also think the VTK format (with cell-type data support as suggested
by Bernhard) is a very good choice. However, what would really really
be nice is to have some well-defined APIs for unified and modularized
mesh/data readers/writers, and further, to implement the VTK (or the
extended .msh format) reader/writer as the reference code conforming
to the API. With this,

* a user can easily create readers/writers of other formats,

and more importantly,

* Gmsh can be extended to a powerful and general-purpose preprocessor
  which can generate not only meshes but also boundary conditions and
  initial value information, since now Gmsh shares topological
  information between mesh and data.

It may not something that can be achieved in the upcoming release but
it would be really nice if realized in the future.

Best regards,
Takuya OSHIMA

From: Christophe Geuzaine <cgeuzaine at ulg.ac.be>
Subject: Re: [Gmsh] Gmsh and postprocessing
Date: Fri, 07 Dec 2007 22:09:26 +0100

> 
> 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