[Gmsh] Virtual topology problem

[Christophe Geuzaine]

> On 23 Jul 2019, at 09:13, Martin Kraska <martin.kraska at th-brandenburg.de> wrote:
> 
> Hello,
> 
> thanks for your immediate response. Yet adding the compound constraint to surfaces 21 and 22 doesn't solve the problem. The virtual topology is still ignored.

No, with the latest dev snapshot this works perfectly:

***
Merge "part.step";

// Virtual topology to avoid enforcing small elements
Compound Curve {63,64};
Compound Curve {65,66};
Compound Surface {23,25};
Compound Surface {9,24,26};
Compound Surface {21};
Compound Surface {22};

// Set definitions
Physical Surface("support") = {5};
Physical Surface("load") = {17};
Physical Volume("part") = {1};

// Mesh control and meshing
Mesh.CharacteristicLengthMax = 7;
***

As explained in my previous email the flow for compounds + second order meshing still needs a little bit of work, as the default (Mesh.CompoundClassify=1) cannot be used for 2nd order meshes, since elements can be classified across surfaces (and hence across parametrizations).

Christophe


> 
> Is that because I didn't "redefine the volume in terms of  the new surfaces"? How would I do this? As I understand your concept of virtual topology, there aren't any new surfaces at all, just meshing constraints. So what should I do to redefine the volume?
> 
> Furthermore, I have to set a rather small element size in order to avoid negative jacobians.
> 
> How about imposing local mesh refinement in areas with invalid elements? That might be a way to automatically resolve such problems in a smarter way than just global refinement.
> 
> <41086788.png>
> Best regards, Martin Kraska
> 
> ----- Am 22. Jul 2019 um 22:42 schrieb Christophe Geuzaine <cgeuzaine at uliege.be>:
> On 22 Jul 2019, at 21:47, Martin Kraska <martin.kraska at th-brandenburg.de> wrote:
>  
>  Hello,
>  
>  in the attached script I try to mesh a step part using virtual topology (trying
>  to update the example
>  https://github.com/mkraska/CalculiX-Examples/tree/master/CAD/OnshapeTutorial )
>  I see that I have to use a new syntax for virtual topology but otherwise did not
>  make any changes compared to gmsh 3.0.3 which I tried last.
>  
>  In gmsh 4.3.0 I get a boundary mesh issue.
>  In 4.4.0 the virtual topology is just ignored but the part is meshed.
>  in the git version of today (2019-07-22) I get a slightly different boundary
>  mesh issue.
>  
>  Did I miss some settings? Or is the part just too nasty?
> 
>  
>  You forgot to set:
>  
>  Compound Surface {21};
>  Compound Surface {22};
>  
>  With these the first order mesh looks OK.
>  
>  Note that the 2nd order mesh will not work - this is currently expected with
>  Mesh.CompoundClassify=1 (the default), as elements are reclassified across the
>  boundaries.
>  
>  We will improve this in the future. In the meantime, you can set
>  Mesh.CompoundClassify=0; but you will need to redefine the volume in terms of
>  the new surfaces. We haven't decided yet what the best/most  natural workflow
>  should be in that case. Any feedback is welcome!
>  
>  Christophe
>  
>  
>  
> 
>  Thanks for any advice, Martin Kraska
>  <vt.zip>_______________________________________________
>  gmsh mailing list
>  gmsh at onelab.info
>  http://onelab.info/mailman/listinfo/gmsh
> 
>  
>  —
>  Prof. Christophe Geuzaine
>  University of Liege, Electrical Engineering and Computer Science
>  http://www.montefiore.ulg.ac.be/~geuzaine
> 
> <part.step><partVT1.geo>

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine