[Gmsh] File formats

[Jean-Francois Remacle]

Le 08-avr.-09 à 11:29, dolfyn a écrit :

> Thank you Christophe!
>
>> you can just put your $NodeData, $ElementData, etc. in
>> separate files, and merge them along with the original mesh :
>>
> ahhh thanks!
>
>> gmsh mymesh.msh res1.msh res2.msh res3.msh
>>
> this means (for me) an option: either to write out in *.msh all data
> OR creating a map (by gmsh2dolfyn: gmsh 3D elements <-> dolfyn
> cells, gmsh 2D named(!) elements <-> dolfyn boundaries). Using the
> map the default boundaries (region 0, when present) will not appear
> in the *.msh file.
>
> splitting the results will mean something like (the method of
> keeping the basename and extended extentions; great idea too for
> unsteady results!):
>
> gmsh mymesh.msh mymesh_uvw.msh mymesh_p.msh mymesh_k.msh
>
> (better this method than using View[i].Visible=0 which means one
> still creates the data set)
>
> Instead of the background mesh; is it possible to ask Gmsh to refine
> certain specific cells? Sent to Gmsh for example by a list?
> The 'injection' of the 'current result' as the starting guess for
> the 'new mesh' would be simple then (only the refined
> elements/cells did change).
>

This feature will be available shortly in gmsh, using the MadLib (www.madlib.be 
).
This library enables to adapt an existing mesh using local mesh  
modification. It uses
gmsh solid model for snapping new vertices on the real geometry.  It  
also
enables several levels of control on the adaptation process (atomic  
local mesh
modifications (swap, collapses, split), global adaptation,...)

A direct plugin of madlib into gmsh will be soon available.

JFR


> Henk
>
>
>
>
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh

----------------
Prof. Jean-Francois Remacle
Universite catholique de Louvain (UCL)
Tel : +32-10-472082 -- Mobile : +32-473-909930