[cgma-dev] Meshquite and iGeom

[Iulian Grindeanu]

Hi Dan, What is your configuration? Did you build cgm with OpenCascade or with Cubit/Acis? I think it is OpenCascade. So are you trying to associate all mesh vertices with the closest surface geometry? Can you send the code you are using to test this? iBase_REGION corresponds to a volume entity in iGeom or to a 3D solid element in iMesh (3D topological entity) From what I see, the geometry and mesh are pretty close to each other. How are you deciding what nodes are on the boundary? Are you using Skinner in moab? Iulian ----- Original Message -----
| Hi,
| I'm still trying to test the relation between mesh and geometric
| model. But there is some problem, when I try to use iGeom
| (iGeom_getEntClosestPt) to compute
| the distance from mesh coordinates and geom surfaces.
| There 2 point which should be on geometric surface, but the computed
| distance are wrong:
| 10990.6 2573.73 0 (computed closest:11202.6 2486.35 0.000607243)
| 10990.6 2573.73 3000 (-->11202.6 2486.36 3000)
| There 're no problem by other points (in ori_mesh.vtk).
| I wonder what happened by the computing. And how exactly does
| iGeom_getEntClosestPt work?
| Best Regards
| Le, Dan
| PS: what's the meaning of iBase_REGION ?
| Am 16.12.2011 06:39, schrieb Iulian Grindeanu:
| | | Mesquite will modify position of the free nodes, to get a better
| | | quality; "constrained nodes" can be constrained on geometry
| | | entity,
| | | so
| | | they can move only along geometry. This is an advanced use of
| | | Mesquite, and you should understand what you can do with it.
| | | Sets of nodes can be constrained to move along geometry; 1d sets
| | | for
| | | geometric edges, 2d sets for faces (while keeping the boundary
| | | nodes
| | | on specific boundary edges too).
| | | This setup may have to be done "by hand", including generation of
| | | sets. How did you create the hexa mesh? The nodes that are on the
| | | boundary may have to be put in sets, for all your edges, faces,
| | | etc.
| | | You have a unit issue with your model; I think that in theory you
| | | can
| | | "squeeze" that vtk file to fit that wall geometry, but I do not
| | | think
| | | that this is the proper way to use mesquite. This is why I
| | | suggested
| | | to look at meshkit examples (only one mesquite test involves
| | | geometry,
| | | and it is too simple)
| | | One would be test_onetooneswept in meshkit/test/algs.
| | | Iulian
| | I was wrong with the suggestion to try test_onetooneswept in
| | meshkit/test/algs.
| | Until this evening, it did not work with OpenCascade;
| | It should work now, if you update MeshKit
| | Also, in Lasso, test_entset will work if you launch it with
| | test_ent brick.stp brick.h5m (update Lasso too, to get those files)
| | Iulian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20120117/1dd890ea/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cduct.igs
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20120117/1dd890ea/attachment-0002.diff>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ori_mesh.vtk
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20120117/1dd890ea/attachment-0003.diff>