Thanks for your reply Christophe.
My concern arises from the fact that I'm using gmsh with an adaptive
routine, I give the size of the element and get the new desired size.
Of course the definition of what is the element size should be
consistent with the approach used by gmsh. So far I'm using
h=(Volume/2)^(1/2) as an approximation to the size but I'm not sure this
is fair enough.
Best,
--
Octavio Andrés González Estrada
Research Associate
Institute of Mechanics and Advanced Materials
Cardiff School of Engineering
Cardiff University
The Parade
Cardiff CF24 3AA, Wales, UK
Email: [email protected]
[email protected]
On 21/08/12 01:25, Christophe Geuzaine wrote:
On 20 Aug 2012, at 22:58, Jö Fahlke <[email protected]> wrote:
Am Mon, 20. Aug 2012, 20:53:23 +0200 schrieb Christophe Geuzaine:
On 20 Aug 2012, at 17:50, Andres Gonzalez Estrada <[email protected]> wrote:
Does anyone have a clue about how gmsh interpret the characteristic lenght?.
The problem has been described before in several post with no successful reply,
e.g.:
Hi Jo - it's the length of mesh edges.
It wasn't me who asked the question this time -- but I'll join the discussion
anyway.
I'm assuming you mean the characteristic length is an upper limit for the edge
length. But that can't be true, or at least there is something missing. In
3D, if I remember correctly, the maximum edge length is usually something like
twice the characteristic length.
To illustrate, please find attached the simple example
unit-square.{geo,msh,pdf}. The mesh was generated with gmsh 2.6.1.dfsg-3 from
Debian. The unit square has a side length of 1, and I used a characteristic
length of 0.1 (by setting the characteristic length at the Points). As you
can see, each side of the unit square is devided into 9 segments, which means
the size of at least one of the segments must be larger than the
characteristic length.
It's just a small numerical integration error (computing the mesh spacing in
the 1D meshing algorithm is obtained through integration--see the Gmsh paper
for more info). Thus try e.g.
Point(1) = {0, 0, 0, 0.09999};
Extrude {1, 0, 0} {
Point{1};
}
Extrude {0, 1, 0} {
Line{1};
}
and you will indeed get 10 elements on each side. You could also add
Mesh.Algorithm=6;//frontal-delaunay
top get a more regular surface mesh, made of quasi-equilateral triangles.
Note that in all cases, the final surface or volume mesh will never have edges
that are all *exactly* equal to the prescribed size. The efficiency index of a
typical mesh will be around 0.8 (see the Gmsh paper for the definition).
Also note that in 3D only the Delaunay algorithm will respect the prescribed
mesh size field. The frontal algorithm based on Netgen does not: it will only
do its best to propagate the mesh size information from the boundaries.
Hope this helps,
Christophe
Regards,
Jö.
--
Jorrit (Jö) Fahlke, Interdisciplinary Center for Scientific Computing,
Heidelberg University, Im Neuenheimer Feld 368, D-69120 Heidelberg
Tel: +49 6221 54 8890 Fax: +49 6221 54 8884
[Zum Thema GNOME 3]
(15:11:22) marina: linus ist auf meiner seite
<unit-square.geo><unit-square.msh><unit-square.pdf>
_______________________________________________
gmsh mailing list
[email protected]
http://www.geuz.org/mailman/listinfo/gmsh
