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 <[email protected]> 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.
signature.asc
Description: Digital signature
_______________________________________________ gmsh mailing list [email protected] http://www.geuz.org/mailman/listinfo/gmsh
