[Gmsh] Characteristic length

[Andres Gonzalez Estrada]

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: agestrada at gmail.com
        estradaoag at cardiff.ac.uk

On 21/08/12 01:25, Christophe Geuzaine wrote:
> On 20 Aug 2012, at 22:58, Jö Fahlke <jorrit at jorrit.de> wrote:
>
>> Am Mon, 20. Aug 2012, 20:53:23 +0200 schrieb Christophe Geuzaine:
>>> On 20 Aug 2012, at 17:50, Andres Gonzalez Estrada <agestrada at gmail.com> 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>