[Gmsh] Virtual topology problem

[Martin Kraska]

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. 

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. 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20190723/9a4e6db4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 41086788
Type: image/png
Size: 86042 bytes
Desc: not available
URL: <http://onelab.info/pipermail/gmsh/attachments/20190723/9a4e6db4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part.step
Type: application/octet-stream
Size: 60917 bytes
Desc: not available
URL: <http://onelab.info/pipermail/gmsh/attachments/20190723/9a4e6db4/attachment-0001.step>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partVT1.geo
Type: application/octet-stream
Size: 1385 bytes
Desc: not available
URL: <http://onelab.info/pipermail/gmsh/attachments/20190723/9a4e6db4/attachment-0001.geo>