[Gmsh] Post processing format

Christophe Geuzaine geuzaine at acm.caltech.edu
Wed Jun 2 07:24:22 CEST 2004


Carl Osterwisch wrote:

> 
> I am interested in writing a translator to post-process results from my
> commercial FEA package.  I have a few questions after reading though
> chapters 9.2 and 9.3 which describe the ascii and binary
> post-processing file formats.
> 
> 1. It appears that all results are element-nodal, associated to a 3D
> coordinate.  Why not refer the results to the integer node and element
> numbers from the original mesh?

It's a deliberate choice: the post-processing format does not assume any
continuity properties of the fields (i.e., "everything is
discontinuous") and does not provide any connectivity information
between the elements.

I guess you could see our post-processing files more as general
"plotting files", rather than "finite element output files". For
example, I mainly use Gmsh's post-processor as a kind of "3D Gnuplot",
without any "finite element" mesh to support my data.

> 
> 2. Second order tetrahedral elements are not yet supported in the post
> processor?

No, not yet.

Actually, since the underlying drawing primitives do not know anything
about curved geometries, the only way to draw higher order elements
would be by subdivision. Right now we leave the subdivision task to the
routines that write the post-processing files (i.e., your code :-)). We
might introduce a standard subdivision scheme in the future (e.g.
assuming the same kind of input as the 2nd order elements the mesh
algorithms generate), but that's not done yet.

> 
> As a suggestion for improvement, it looks like the version 2.0 mesh
> file format could be extended to address these issues with additional
> headings such as:
> $NodeView
> Temperature
> 1 20.0
> 2 21.2
> 3 25.6
> $EndNodeView
> 

Yes, we thought about this (but that could only be a particular case, as
it assumes that your field is continuous--and that you actually have a
"mesh", not just a bunch of triangles).

There will maybe be something like that in a future version, but at the
moment, except for the saving in file size, I'm not sure it's worth the
extra code...

Best,

C.

-- 
Christophe Geuzaine
Applied and Computational Mathematics, Caltech
geuzaine at acm.caltech.edu - http://geuz.org