> 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
_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh
