[Gmsh] Virtual topology problem

Thu Jul 25 14:22:50 CEST 2019

> On 25 Jul 2019, at 00:23, Martin Kraska <martin.kraska at th-brandenburg.de> wrote:
> 
> Hi Christophe,
> 
> Thank you for the explanation and for making a nice example based on the problem case.
> I would appreciate a link to the related page of my CalculiX example collection 
> 
> https://github.com/mkraska/CalculiX-Examples/tree/master/CAD/OnshapeTutorial 
> 

Ok, done.

> I'll add a link to your example as well.
> 
> BTW, I am fine with the limitation to the compound entities for classification in higher order meshes. I hardly want to apply boundary conditions or properties (that's where classification might be required) to some geometry detail while not caring about representing this detail in the mesh. 

Ok.

> 
> I tested the script and indeed it works with the latest dev version. However, the mesh is severly overrefined just to avoid negative jacobians in critical regions. I still have to learn how to identify these regions and how to efficiently specify appropriate local refinement.

To untangle and guarantee the validity of the coarse high-order mesh you can use our high-order optimization algorithms (see http://gmsh.info/doc/preprints/gmsh_untangling_preprint.pdf). On the command line: -optimize_ho.

> 
> However, I observed another problem: The nodes on the concave cylindrical surface are severly off the surface. Looks like a bug to me.
> 

This is normal: compound meshes are generated from the union of the meshes of the compound parts - new points are generated on the discrete representation, not on the CAD. (It's the same principle as when we remesh e.g. an STL file.)

The issue here is that the parts are meshed individually with the same mesh size as the final compound mesh, which indeed gives poor resulting in the curved areas. I just introduced a new parameter to mitigate this issue: Mesh.CompoundCharacteristicLengthFactor. The default value is 0.5, meaning that individual parts are meshed with a finer resolution (half-size) compared to the final mesh. This seems to be a good compromise, but you can of course reduce the value to increase the accuracy. I've modified the example to use this.

Thanks for the feedback,

Christophe

> <6523.png>
> <77323.png>
> 
> Mit freundlichen Grüßen/Best regards
> 
> Prof. Dr.-Ing. Martin Kraska
> Werkstoff- und Strukturmechanik/Mechanics of Materials and Structures
> Maschinenbau/Mechanical Engineering
> Fachbereich Technik
> 
> Technische Hochschule Brandenburg
> University of Applied Sciences
> Magdeburger Str. 50
> 14770 Brandenburg an der Havel
> Raum: 401 IWZ
> 
> Postanschrift: Postfach 2132
> 14737 Brandenburg an der Havel
> 
> T +49 3381 355 356
> F +49 3381 355 66 356
> kraska at th-brandenburg.de 
> Web:
> Martin Kraska
> Offene Werkstatt der THB
> Studiengang Maschinenbau
> 
> ----- Am 24. Jul 2019 um 16:14 schrieb Christophe Geuzaine <cgeuzaine at uliege.be>:
> Hi Martin,
> 
> The "little bit of work" has been done to automate the procedure so that
> compounds can now be used for high-order meshes. In short:
> 
> - With Mesh.CompoundClassify=1, triangles are magically reclassified on the
> original surfaces. This is great for keeping e.g. Physical groups persistent
> across compound mesh definitions, but will prevent e.g. high-order meshing, as
> the parametric coordinates of an element can span several surfaces.
> 
> - With Mesh.CompoundClassify=0, triangles are classified on a new (discrete)
> surface, and the volume mesh now automatically uses these surfaces instead of
> the original ones, which allows for correct high-order meshing and other
> post-processing algorithms. Any reference to the original surfaces (e.g. in
> physical groups) must however be updated.
> 
> We have added your example with the 2 scenarios to our testsuite:
> https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/step/part_compound_curved_mesh.geo
> 
> Let us know if we should add a reference in the .geo file to the original
> source/author/...
> 
> Cheers,
> 
> Christophe
> 
> 
> 
> On 23 Jul 2019, at 20:40, Christophe Geuzaine be> wrote:
> 
> 
> 
> On 23 Jul 2019, at 09:13, Martin Kraska  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
> be>:
> On 22 Jul 2019, at 21:47, Martin Kraska  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>geo>
> 
> 
> —
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
> 
> 
> —
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine

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