[Gmsh] Geometric scaling of STP files
Bill Milewski
bmilewski at aphysci.com
Thu Apr 15 20:03:38 CEST 2010
Hi Prof. Remacle,
Thanks for the response.
Ive 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 Ive
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>