[cgma-dev] question about iges format (to Jane)

Wed Jan 18 21:25:10 CST 2012

Thanks Jane, It is not urgent from my point of view. It is better to have a well thought solution. Are there other geometry formats that have the unit embedded? Should we maybe establish an option, for iGeom load file, that will allow for a conversion (as a last resort?) In general, I don't think we "support" unit conversion anywhere. It is a complicated process, in general, although for geometry / mesh generation point of view, only length units are needed. Thanks, Iulian ----- Original Message -----
| --- On Wed, 1/18/12, Iulian Grindeanu <iulian at mcs.anl.gov> wrote:
| | From: Iulian Grindeanu <iulian at mcs.anl.gov>
| | Subject: Re: [cgma-dev] question about iges format (to Jane)
| | To: "Jane Hu" <janejhu at gmail.com>
| | Cc: "jiangtao ma" <jiangtao_ma at yahoo.com>, "CGMA Development"
| | <cgma-dev at mcs.anl.gov>
| | Date: Wednesday, January 18, 2012, 2:06 PM
| | Hi Jane,
| | Thank you for looking into this.
| | So I verified that with this fix, the output coordinates in
| | testgeom_occ are the same with the one from testgeom.
| | This is "hardcoded", so all iges files read by occ will be
| | "converted"
| | to M.
| | That's why I haven't checked in the code yet.
| | What field in igs file shows that the unit is M? Or is MM? I am
| | still
| | confused who does the conversion to MM, OCC igs reader ?
| | In the iges file first several lines, with a 'G' in the 73th column,
| | you can find a 1HM, which shows the unit is one charactor 'M', if
| | it's
| | MM, it'll be 2HMM. The conversion to MM is done in Opencascade
| | reader,
| | we need to set up the global unit outside it to prevent the
| | conversion
| | in this case.
| | What I need to do is to add code in cgm to read iges/step file about
| | the unit, and assign it to the reader, so it won't be hard coded to
| | M.
| | I may take tomorrow off since I agreed to give a talk to my son's
| | preschool about Chinese New Year, I'll try to fix it as soon as
| | possible.
| | Jane
| | Anyway, this has implications for MOAB too. With the current code,
| | moab will convert the igs file to a faceted model, and in case of
| | OCC
| | it takes forever to facet (I think we have a unit issue there, as we
| | use an absolute value for facet size, not a relative size of model)
| | I mean, if you do "mbsize cducts.igs" for mbsize built with OCC, it
| | will not finish in more than 3 minutes I waited (I had to kill the
| | process). I need to try after this fix.
| | While mbsize cducts.igs for moab built with cubit, finishes almost
| | instantly.
| | Again, mbsize <>.igs will do a faceting of geometry first, then will
| | output the size of the (faceted) mesh.
| | Thanks,
| | Iulian
| | | I need to code for reading the unit of iges, and set up the unit
| | | in
| | | the cgm.
| | | For now, if you already knows the unit of the iges files, here is
| | | meter, then just add the following lines to OCCQueryEngine.cpp
| | | should
| | | work. Please let me know if it temporarily solves your problem.
| | | --- OCCQueryEngine.cpp (revision 5293)
| | | +++ OCCQueryEngine.cpp (working copy)
| | | @@ -32,6 +32,7 @@
| | | #include "gp_Ax2.hxx"
| | | #include "Geom_Surface.hxx"
| | | #include "Geom_Curve.hxx"
| | | +#include "Interface_Static.hxx"
| | | #include "BRepBuilderAPI.hxx"
| | | #include "BRepBuilderAPI_Transform.hxx"
| | | #include "BRepBuilderAPI_GTransform.hxx"
| | | @@ -1491,6 +1492,9 @@
| | | else if(strcmp(file_type, "IGES") == 0)
| | | {
| | | IGESControl_Reader reader;
| | | + char* name = "xstep.cascade.unit";
| | | + char* val = "M";
| | | + Interface_Static::SetCVal (name, val);
| | | const Standard_CString string1 = file_name;
| | | IFSelect_ReturnStatus stat = reader.ReadFile( string1);
| | | if (stat != IFSelect_RetDone)
| | | Thanks.
| | | Jane
| | | On Wed, Jan 18, 2012 at 10:21 AM, Jane Hu < janejhu at gmail.com >
| | | wrote:
| | | | Hi, Iulian,
| | | | Opencascade internally assumes that OCC models are measured in
| | | | millimeters, so if the model is given in unit M (meter), it'll
| | | | be
| | | | changed to 1000times larger and uses MM(millimeter) in OCC. I am
| | | | now
| | | | checking on the code, and see if we can do something on it.
| | | | Jane
| | | | On Wed, Jan 18, 2012 at 9:14 AM, Iulian Grindeanu <
| | | | iulian at mcs.anl.gov
| | | | > wrote:
| | | | | Hi Jane,
| | | | | Dan Le found this problem with respect to igs reader:
| | | | | Please see the attached files.
| | | | | testgeom.cc is a version of CGM/itaps/testgeom.cc file, which
| | | | | also
| | | | | prints the coordinates of all the vertices from the model.
| | | | | iges format is supported by OCC and Acis/cubit engines.
| | | | | Still, the coordinates of the vertices are 1000 larger when
| | | | | occ
| | | | | is
| | | | | used.
| | | | | So if you run this test
| | | | | testgeom cduct.igs
| | | | | in Cubit based cgm or
| | | | | testgeom_occ cduct.igs
| | | | | in OCC based cgm,
| | | | | you get different results (1000 times bigger in occ case). It
| | | | | seems
| | | | | that in cubit case, we do a conversion to sat format, first.
| | | | | ITAPS GEOMETRY INTERFACE TEST PROGRAM:
| | | | | gLoad: Reading STEP/IGES file
| | | | | '/home/iulian/tmp/test_lorenzo/cduct.igs'...
| | | | | Model conversion succeeded: /tmp/CBT.Hoo5yc.sat
| | | | | Read 6 ACIS Entities from the input file
| | | | | Constructed 6 Volumes: 1 to 6
| | | | | Model contents:
| | | | | vertices: 24
| | | | | edges: 24
| | | | | faces: 6
| | | | | regions: 6
| | | | | vertex index 0 : 0 0 0
| | | | | vertex index 1 : 0 1 0
| | | | | vertex index 2 : 10.5 15 0
| | | | | vertex index 3 : 11.5 15 0
| | | | | ...
| | | | | testgeom_occ cduct.igs
| | | | | Geometry engine set to: OpenCascade 6.3
| | | | | ITAPS GEOMETRY INTERFACE TEST PROGRAM:
| | | | | gLoad: Total number of loaded entities : 78.
| | | | | Constructed 6 Volumes: 1 to 6
| | | | | Model contents:
| | | | | vertices: 24
| | | | | edges: 24
| | | | | faces: 6
| | | | | regions: 6
| | | | | vertex index 0 : 0 0 0
| | | | | vertex index 1 : 0 1000 0
| | | | | vertex index 2 : 10500 15000 0
| | | | | vertex index 3 : 11500 15000 0
| | | | | ...
| | | | | Can you please tell me what we should do to get similar
| | | | | results
| | | | | ?
| | | | | Thanks,
| | | | | Iulian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20120118/8d2c8f22/attachment.htm>