[Gmsh] Extremely small ratio of the smallest characteristic length to the size of the model leads to an error (self intersecting surface mesh)

[Juha Ritala]

It seems that I managed to solve the problem now. The solution was to 
divide the large air container around the AFM probe into a small 
cylinder just around the probe and a large cylinder outside it. This way 
all the tiny geometrical details are enclosed within the small cylinder. 
Apparently, a surface with extremely small geometrical details compared 
to the size of the surface is hard to handle. I can now use the default 
value of Mesh.RandomFactor and everything works just fine. The tolerance 
value of Tetgen must still be decreased from the default one though.

Based on my findings, I recommend that an option to change the tolerance 
value of Tetgen would be added to Gmsh. Also, a guide to solve this kind 
of a problem using the divide and conquer strategy described above and 
tuning the tolerance value of Tetgen could be added to the documentation.

Juha

On 2014-02-24 18:14, Juha Ritala wrote:
> Here is some extra information and clarification:
>
> - I am using the newest version of Gmsh (2.8.4) on Ubuntu 12.04. I 
> have also tested 2.8.3 but it does not work any better.
>
> - I can now confirm that changing the tolerance value of Tetgen is 
> crucial if I want to set the characteristic length at the tip to 0.2 nm.
>
> - The value of Mesh.RandomFactor definitely plays some role too.
>
> - The meshing process leads to an error depending on the generated 
> random number sequence. The seed of the random number generator 
> determines whether the meshing is successful or not.
>
> Juha
>
> On 2014-02-20 16:18, Juha Ritala wrote:
>> Hi,
>>
>> I have used the geometry module of Gmsh to model one quarter of a 
>> cylinder symmetric system representing the cantilever and tip of an 
>> atomic force microscope (AFM) on top of a sample (see the attached 
>> .geo file). My goal is to compute the electric field between the AFM 
>> probe and the back plate when a bias voltage is applied between 
>> those. The distance between the tip and the sample (h) can be as 
>> small as 1 nm, whereas the radius and height of the container (Lc) is 
>> 20 mm to justify setting the electrostatic potential to zero at the 
>> boundary.
>>
>> If I set the distance between the AFM tip and the sample to 1 nm, the 
>> characteristic length of the mesh around the tip (tip_ls) must 
>> obviously be smaller than that. Using a characteristic length of 
>> exactly 1 nm usually results in a successful mesh generation, but if 
>> I set the characteristic length to be smaller than 1 nm, the 3D 
>> meshing process gives me a self intersecting surface mesh error. I 
>> suspect this is caused by the extremely small ratio of the 
>> characteristic length at the tip to the size of the model. If I set 
>> the characteristic length at the tip to 0.2 nm, this ratio is 10^-8.
>>
>>
>> I have no prior knowledge of mesh generation algorithms, but it seems 
>> to me that this is either a tolerance or a numerical precision 
>> problem. I have made the following attempts to solve the problem:
>>
>> The most notable attempt I made was to change the tolerance of the 
>> Tetgen algorithm, which is the first part of the 3D meshing, and 
>> where the self intersecting surface mesh error arises. Changing the 
>> tolerance from the default value of 10^-8 to 10^-9 seems to have a 
>> clear positive impact on the success of meshing. Without this change, 
>> the meshing fails always if the characteristic length at the tip is 
>> set to 0.2 nm. With this change, I have managed to generate a good 3D 
>> mesh, although the meshing still randomly fails. I have not yet tried 
>> to set the tolerance even smaller, as changing the tolerance of the 
>> Tetgen requires recompilation of the source.
>>
>> I have tried to tune the options that are on the first lines of my 
>> .geo file. The option Mesh.RandomFactor seems to have a clear impact 
>> on the meshing process. It seems that a smaller value is better, but 
>> the 2D meshing fails if the value is too small. According to the 
>> documentation, too small value of Mesh.RandomFactor leads to problems 
>> with numerical precision.
>>
>>
>> The questions I have are:
>> Has someone else had this kind of a problem? Am I on the right with 
>> my solution attempts? Is there something else that can be done? Where 
>> is the value of Mesh.RandomFactor actually used?
>>
>>
>> Best regards,
>> Juha
>>
>>
>>
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh

-- 
Juha Ritala
Department of Applied Physics
Aalto University, Finland
juha.ritala at aalto.fi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20140226/5f457193/attachment.html>