MantisBT - Open CASCADE
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0031449Open CASCADE[OCCT] OCCT:Meshpublic2020-03-20 09:162020-08-28 15:43
Reporterabv 
Assigned Tooan 
PrioritynormalSeverityminor 
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.6.0*Fixed in Version 
Test case number
Summary0031449: Mesh - BRepMesh works too long and produces many free nodes on a valid face
DescriptionThe 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".
Steps To Reproduce1. 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:

pload MODELING MESH
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):

pload MODELING
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)
Additional information
and documentation updates
TagsNo tags attached.
Relationships
related to 0025287closed bugmaster Community BRepMesh_IncrementalMesh produces (way) out of tolerance mesh 
Attached Files? bug31301_face_loopback_M.brep (24,500) 2020-03-20 09:16
https://tracker.dev.opencascade.org/
png free_nodes_axo.png (4,333) 2020-03-20 10:55
https://tracker.dev.opencascade.org/
png free_nodes_UV.png (2,096) 2020-03-20 10:56
https://tracker.dev.opencascade.org/
Issue History
Date ModifiedUsernameFieldChange
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*

Notes
(0091075)
oan   
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.