[Gmsh] Industrial Applications of Intermediate Complexity

[Christophe Geuzaine]

Jacques - Thanks for the feedback! Some partial answers below...

Jacques Kools wrote:
>
> b) It would be useful at times to have an  "unclick" option in the
> GUI, especially for complex 3D geometries: If you have to select a
> large number of objects in a complex model ( e.g. to define a surface
> loop), you might click on the wrong surface. If you can just unclick
> the last object, you do not have to start all over again.

That's a good idea. I added this to our TODO list.

>
> c) I find that the communication between GMSH and GetDP is not always
> working from the first time under Windows, but it works well under
> Linux. (Very minor issue)

Do you have the tools to recompile getdp on your machine? If you do,
could you try to slightly increase the delay before we try to connect to
the server? You can do that by modifying the Socket_Idle() call in
getdp/Main/GmshClient.c (line 93).

>
> 2) I find that, as you warned in the introduction of the manual, that
> the 3D meshing algorithm becomes the time limiting step for this kind
> of calculations (not the solver ). I looked into this a little bit
> and noticed the following: During the last step of the 3D meshing (
> when something is converging to 0.8), the memory allocation of the
> program increases substantially. For example, while calculating a
> mesh with a final size of about 20-30MB, the program has several
> hundreds of MB allocated at some time ! On a windows box ( especially
> the ones with low DRAM) the OS becomes unstable, while Linux starts
> using the hard drive as overflow,  decreasing the speed with a factor
> of 100 or so !!
>
> Here's my question : Could it be that there is some redundant memory
> allocation during that step ? (I noticed a hint of a similar issue in
> 2D in the release notes of version 1.31. ).
>

Yep, we should spend some time optimizing the 3D code (for speed and
memory)... There are still a couple of serious memory leaks in Gmsh, but
most of them are in the old 2D algorithm.

Best,

Christophe

-- 
Christophe Geuzaine
Applied and Computational Mathematics, Caltech
geuzaine at acm.caltech.edu - http://geuz.org