[Gmsh] Geometric scaling of STP files

[Bill Milewski]

Hi Prof. Remacle,

 

Thanks for the response.

 

I’ve attached copies of IGES files and output meshes from GMSH.  The “test1”
files show the issue with scaling whereas the “test2” files do not.  I used
units of meters in Rhino for the “test1” file and millimeters for the
“test2” files.  It appears that there is a default setting of millimeters
somewhere in the OpenCascade routines that causes the problem that I’ve
observed.  I should be able to complete my current task, but it would be
nice to have a better understanding of the default values and limitations of
the CAD model.

 

Best regards,

 

Bill

 

  _____  

From: Jean-Francois Remacle [mailto:jean-francois.remacle at uclouvain.be] 
Sent: Thursday, April 15, 2010 12:56 PM
To: Bill Milewski
Cc: gmsh at geuz.org
Subject: Re: [Gmsh] Geometric scaling of STP files

 

 

Le 14-avr.-10 à 22:47, Bill Milewski a écrit :





Hi,

 

I recently started working with GMSH and have encountered odd behaviors
related to scaling geometry imported from Rhinoceros CAD via STEP or IGES
files.  I have not seen anything in the FAQ or Wiki related to these issues.

 

1.	Where is the default geometric scale factor set?  (I am using the
GUI initially.)  The coordinates in the STEP file are consistent with my CAD
model.  When I save GEO and MSH files from gmsh the coordinates all seem to
be scaled by a factor of 1000 for one model.  However, for a second model
the scale is correct.

 

We use the OpenCascade STEP import. Maybe we missed something related to
units. Can you give us examples

of such problematic behavior ?

 





1.	 
2.	Does the Bspline algorithm handle non-uniform weights, repeated
control points and multiple internal knots correctly?  I have a body of
revolution, with singularities at the poles, that seems to behave in a funny
way.

 

 

 

I guess OpenCascade supports NURBS ;-)

 

Yet, singularities in mappings may result in problematic behaviors in
meshers. Gmsh's meshers

make use of surface metrics that are typically singular at poles. We try to
do our best, and some

enhancements in the meshers are scheduled for removing singularities (you
can try compound 

surfaces for that , and there is a wiki !!)

 

JFR

 

 





Best regards,

 

Bill

 

Bill Milewski, Ph.D.

 

_______________________________________________
gmsh mailing list
gmsh at geuz.org
http://www.geuz.org/mailman/listinfo/gmsh

 

------------------------------------------------------------------

Prof. Jean-Francois Remacle

Universite catholique de Louvain (UCL)

Ecole Polytechnique de Louvain (EPL) - Louvain School of Engineering

Institute of Mechanics, Materials and Civil Engineering (iMMC)

Center for Systems Engineering and Applied Mechanics (CESAME)

Tel : +32-10-472352 -- Mobile : +32-473-909930 

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20100415/47ee8d62/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.igs
Type: application/octet-stream
Size: 22194 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20100415/47ee8d62/attachment.igs>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.msh
Type: application/octet-stream
Size: 25448 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20100415/47ee8d62/attachment.msh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.igs
Type: application/octet-stream
Size: 22194 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20100415/47ee8d62/attachment-0001.igs>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.msh
Type: application/octet-stream
Size: 25781 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20100415/47ee8d62/attachment-0001.msh>