[Gmsh] Characteristic length

[Jö Fahlke]

Hi Christophe,

thanks for your answer, I think it finally help clearing up my biggest
misunderstanding about the characteristic length :)

Am Tue, 21. Aug 2012, 02:25:29 +0200 schrieb Christophe Geuzaine:
> 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:
> > 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.

Alright, that assumption is wrong (see below), ...

> > To illustrate, please find attached the simple example
[...]
> 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};
>   }

...which, together with rounding down, explains how a numerical error can
cause 9 segments, where I would have expected all it can cause is 11 segments.

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

I was more interested in and upper limit on the size of the edges, i.e. edges
are guaranteed to be smaller than that limit.  Although I have to say that for
me this feature was more a nice-to-have and isn't a current issue anymore.

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

Considering a homogeneous mesh size field, does that mean the mesh size
information for both Delaunay and Netgen will be same?



Having looked a bit closer at the paper, it is my understanding that:

 1. The characteristic length in itself is not an upper limit of the edge
    length, rather, it is considered the optimal edge length.  Both longer and
    shorter edges are allowed, but penalized and lead to a lower efficiency
    index (equation (2)).

 2. For *2D* using MeshAdapt (as described in the paper): the algorithm tries
    hard to keep the edge length within a range of 0.7 to 1.4 times the
    characteristic length.

Even considering the paper, the 9-mesh-edges-per-model-edge phenomenon still
required some guessing to explain.  Consider equation (3), which is used to
calculate the number of mesh edges per model edge.  In the case of
unit-square.geo it *should* yield N=10, but due to numerical errors it *may*
yield something like N=0.9999 or N=10.0001.  I suppose the actual integral N
is obtained by using truncate() or similar (like simply assigning a double to
an integer); that would explain the observed behaviour.

But it seems strange to me that truncate() is used here -- in ~50% of cases it
will lead to a larger deviation from the characteristic length than necessary.
Rather, I would have expected something like round(), or even something a
little more elaborate.

Am I totally off-track, or is there a reason for using truncation rather than
rounding, or was it just not considered an issue?  After all, it doesn't make
much of a difference for large N...

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

Interpunktion, Orthographie und Grammatik der Email ist frei erfunden.
Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein
zufällig und ist nicht beabsichtigt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20120826/b485557d/attachment.asc>