MantisBT - Open CASCADE
View Issue Details
0031449Open CASCADE[OCCT] OCCT:Meshpublic2020-03-20 09:162020-08-28 15:43
[OCCT] 7.6.0* 
0031449: Mesh - BRepMesh works too long and produces many free nodes on a valid face
The shape analyzed in context of #31301 exhibits problems in meshing occuring after export of the original shape (initially imported from STEP) to STEP and importing back, in a case when parameter xstep.cascade.unit is set to meters during last import. The meshing takes enormous time (effectively hangs) and (when suceeds) produces a lot of free nodes.

Originally detected in CAD Assistant which just hangs and eats all available memory when reading the exported STEP file if unit settings are "M".
1. Full variant of original sequence in DRAW (hang or too long to wait for):

pload XDE AISV
ReadStep D [locate_data_file bug31301.stp]
WriteStep D bug31301_exported.stp
param xstep.cascade.unit M
ReadStep Q bug31301_exported.stp
XShow Q
----> WAIT (forever?)!

2. Simplified variant (prototype of test case) using single face (one that caused problems in #31301) already passed through all import - export steps:

restore [locate_data_file bug31301_face_loopback_M.brep] a
checkshape a
tolerance a

dchrono s restart
incmesh a 0.0001
dchrono s stop show
# meshing must be fraction of second, takes ~ 30 sec

tricheck a
# 6.000+ free nodes

3. Reproduction of the situation of CAD Assistant that eats ~ 30 GB of memory in ~ 3 min (on 6-core CPU):

restore [locate_data_file bug31301_2_exported.brep] a
incmesh a 0.00039624 -a 20 -min 0.0001 -parallel

(the file is attached to #31301)
No tags attached.
related to 0025287closed bugmaster Community BRepMesh_IncrementalMesh produces (way) out of tolerance mesh 
? bug31301_face_loopback_M.brep (24,500) 2020-03-20 09:16
png free_nodes_axo.png (4,333) 2020-03-20 10:55
png free_nodes_UV.png (2,096) 2020-03-20 10:56
Issue History
2020-03-20 09:16abvNew Issue
2020-03-20 09:16abvAssigned To => oan
2020-03-20 09:16abvFile Added: bug31301_face_loopback_M.brep
2020-03-20 09:16abvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=22693#r22693
2020-03-20 09:16abvRelationship addedchild of 0031301
2020-03-20 10:12oanRelationship addedrelated to 0025287
2020-03-20 10:44abvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=22699#r22699
2020-03-20 10:44abvFile Added: bug31301_2_exported.brep
2020-03-20 10:47abvFile Deleted: bug31301_2_exported.brep
2020-03-20 10:47abvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=22700#r22700
2020-03-20 10:54oanNote Added: 0091075
2020-03-20 10:55oanFile Added: free_nodes_axo.png
2020-03-20 10:56oanFile Added: free_nodes_UV.png
2020-03-20 11:00oanNote Edited: 0091075bug_revision_view_page.php?bugnote_id=91075#r22702
2020-08-28 15:43oanTarget Version7.5.0 => 7.6.0*

2020-03-20 10:54   
(edited on: 2020-03-20 11:00)
It is strange, but reported free nodes are all visually located out of face boundary (see attached screenshots). To be analysed.