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 <[email protected]> wrote: > > > >> On 23 Jul 2019, at 09:13, Martin Kraska <[email protected]> >> 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 >> <[email protected]>: >> On 22 Jul 2019, at 21:47, Martin Kraska <[email protected]> >> 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 >> [email protected] >> 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 — Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine _______________________________________________ gmsh mailing list [email protected] http://onelab.info/mailman/listinfo/gmsh
