August 2015 - cgma-dev - mailman3.cels.anl.gov

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Vander Zee, Evan B. 28 Aug '15

28 Aug '15

In review of the pull request I created, it came up that the read_cgm_senses_test of MOAB was broken by this change. I have pushed an updated version of that test to a vanderzee/faceVolSense branch of the MOAB repository. With that change, my local build of moab-oce passes all of the tests in make check. This particular test has hard-coded what face-to-volume and edge-to-face senses it expects to get when it reads MeshFiles/unittest/io/cylcube.stp file. The geometry contains two volumes, a cube and a cylinder, that do not touch or overlap. Since my changes to CGM now produce normal vectors and face-to-volume senses that are in accordance with what is stored in the .stp file rather than always producing a forward sense on all faces and not having the sense in accordance with the normal vector, and since some of the faces in the .stp file have reversed sense, the face-to-volume and edge-to-face senses that this test expects needed to be changed. In the attached spreadsheet – which I think will open in OpenOffice if you don’t have Excel – I describe the changes I’ve made in a way that’s probably a bit easier to understand than the code. I have an initial table that shows how all 10 faces expected a forward (F) sense, but now half of them expect a reverse (R) sense. In the lower table I list the edge-to-face senses. Here the expectation is that wherever the sense of a face has changed to the reverse sense, the sense of the edge with respect to that face should flip. You should be able to see how my changes respect that. Also, the order in which the edges are read changed slightly, so edges 6 and 8 swapped IDs. I also made some changes to the check_sense_data method of the test so that the test does not depend on having the known senses and the senses read from the file in the same order. This seemed to be the intent of that method, but was not behaving that way. If the test is supposed to depend on reading things in the same order, you can revert the two lines I added to that method, and the test will still pass. Finally, I changed the test to check the face-to-volume senses before it checks the edge-to-face senses, because the expectation one has for edge-to-face sense depends on the face-to-volume sense. That reflects a preference that I have, but again, is not at all essential. -Evan From: jain(a)mcs.anl.gov [mailto:[email protected]] Sent: Wednesday, August 26, 2015 4:50 PM To: Vander Zee, Evan B.; cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Yes, create a PR. We'll run in through buildbot. Rajeev Jain Software Development Specialist MCS, Argonne National Laboratory 1147, Bldg 240, O: 630-252-3176 Gmail: rajeeja GVoice 312-RAJ-EEV0 jain(a)anl.gov<mailto:[email protected]> On Wednesday, August 26, 2015 4:42 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> wrote: I have pushed up my changes to the vanderzee/faceVolSense branch. Should I create a pull request for this branch? At this point I do not follow the convention of having surfaces oriented to return outward-facing normals if there is only one volume. Instead, I updated the code so that if you ask for the face-to-volume sense, then you will get the proper answer – forward if the normal faces outward and reversed if the normal faces inward. Moreover, the facets that are returned from get_graphics agree with the normal vector, i.e., they are oriented to be counterclockwise if you were looking down at the surface from the direction that the normal points toward. In other words, the triangle normal computed by the cross product of v1 – v0 with v2 – v0 would point in the same direction as the surface normal. I think this works in most situations, but I suspect that there are some corner cases that I do not know enough about where this would fail. In particular, I am concerned that merge, imprint, or other cases that make essential use of the bridge_sense may fail. Please let me know if you run across a case where what I’ve described is not the case. If we require support for getting all of the triangles returned from get_graphics to be counterclockwise with respect to normals facing outward from a particular volume, then let’s discuss what an appropriate API would be for supporting that use case. It should be quite easy to implement something like that now, but in my opinion the API would have to include specifying the volume from which you want the triangle normal vectors to face outward. -Evan From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Vander Zee, Evan B. Sent: Wednesday, August 26, 2015 11:57 AM To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 I’ve found the problem. My original diagnosis was incorrect. Here’s what the problem was. For the Cubit-generated bricks I was not traversing the edges in the expected order, so after I set up all of the edge senses properly, some later code was reversing all of the edge senses for the Cubit-generated files. When I changed the code to traverse the edges in the expected order, I pass my modified test_edge_orient for brick_2.stp as well as for a box created inside of CGM and when reading the file that contains the box created inside of CGM. After the latest code change, a new test is failing. This is the point_project test. The way the test is written, it projects a point onto a surface using the closest_point_trimmed method. There are two edges that the point could project onto that are equally close. In the current CGM/OCC implementation, the edge that is chosen depends on the internal ordering of the edges, so it makes sense that my code changes could have flipped the test to choose the other of the two equally close edges. I don’t see any documentation saying that the tie should be broken in a particular fashion, so I plan to change the test to allow projecting the point to either of the equally close edges. Thanks for your help. You should see some commits to my vanderzee/faceVolSense branch later today after I clean up the code a bit. -Evan From: jain(a)mcs.anl.gov<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, August 26, 2015 10:41 AM To: Vander Zee, Evan B.; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Cc: Andrew Davis Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan, I'd say get the same file from CUBIT and from OCC directly, compare, but follow and adhere to OCC and submit a patch to CUBIT to update their CGM. In my understanding CUBIT gets STEP support via CGM. Specifically these two dev-lists would be better for specific discussions and understanding: 1. OCE dev list: https://groups.google.com/forum/#!forum/oce-dev 2. CUBIT help list: cubit-help(a)sandia.gov<mailto:[email protected]> == Rajeev Jain Software Development Specialist 1134, Building 240 Mathematics and Computer Science Division Argonne National Laboratory Argonne IL, 60439, USA O: 630-252-3176 Google: rajeeja, Voice: 312-725-3380 == On Tuesday, August 25, 2015 3:54 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> wrote: I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. At http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided at http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web page http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__s…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edge should not be multiplied by the sense of the advanced face. I haven’t finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]>> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]> You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov<mailto:[email protected]> When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> To: "Jain, Rajeev" <jain(a)mcs.anl.gov<mailto:[email protected]>> Cc: "cgma-dev(a)mcs.anl.gov<mailto:[email protected]>" <cgma-dev(a)mcs.anl.gov<mailto:[email protected]>> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov<mailto:[email protected]>> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov<mailto:[email protected]> ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov<mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by jain＠mcs.anl.gov 26 Aug '15

26 Aug '15

Yes, create a PR. We'll run in through buildbot. Rajeev Jain Software Development Specialist MCS, Argonne National Laboratory 1147, Bldg 240, O: 630-252-3176 Gmail: rajeeja GVoice 312-RAJ-EEV0 jain(a)anl.gov On Wednesday, August 26, 2015 4:42 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov> wrote: I have pushed up my changes to the vanderzee/faceVolSense branch. Should I create a pull request for this branch? At this point I do not follow the convention of having surfaces oriented to return outward-facing normals if there is only one volume. Instead, I updated the code so that if you ask for the face-to-volume sense, then you will get the proper answer – forward if the normal faces outward and reversed if the normal faces inward. Moreover, the facets that are returned from get_graphics agree with the normal vector, i.e., they are oriented to be counterclockwise if you were looking down at the surface from the direction that the normal points toward. In other words, the triangle normal computed by the cross product of v1 – v0 with v2 – v0 would point in the same direction as the surface normal. I think this works in most situations, but I suspect that there are some corner cases that I do not know enough about where this would fail. In particular, I am concerned that merge, imprint, or other cases that make essential use of the bridge_sense may fail. Please let me know if you run across a case where what I’ve described is not the case. If we require support for getting all of the triangles returned from get_graphics to be counterclockwise with respect to normals facing outward from a particular volume, then let’s discuss what an appropriate API would be for supporting that use case. It should be quite easy to implement something like that now, but in my opinion the API would have to include specifying the volume from which you want the triangle normal vectors to face outward. -Evan From: cgma-dev-bounces(a)mcs.anl.gov [mailto:[email protected]]On Behalf Of Vander Zee, Evan B. Sent: Wednesday, August 26, 2015 11:57 AM To: cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 I’ve found the problem. My original diagnosis was incorrect. Here’s what the problem was. For the Cubit-generated bricks I was not traversing the edges in the expected order, so after I set up all of the edge senses properly, some later code was reversing all of the edge senses for the Cubit-generated files. When I changed the code to traverse the edges in the expected order, I pass my modified test_edge_orient for brick_2.stp as well as for a box created inside of CGM and when reading the file that contains the box created inside of CGM. After the latest code change, a new test is failing. This is the point_project test. The way the test is written, it projects a point onto a surface using the closest_point_trimmed method. There are two edges that the point could project onto that are equally close. In the current CGM/OCC implementation, the edge that is chosen depends on the internal ordering of the edges, so it makes sense that my code changes could have flipped the test to choose the other of the two equally close edges. I don’t see any documentation saying that the tie should be broken in a particular fashion, so I plan to change the test to allow projecting the point to either of the equally close edges. Thanks for your help. You should see some commits to my vanderzee/faceVolSense branch later today after I clean up the code a bit. -Evan From:[email protected] [mailto:[email protected]] Sent: Wednesday, August 26, 2015 10:41 AM To: Vander Zee, Evan B.; cgma-dev(a)mcs.anl.gov Cc: Andrew Davis Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan, I'd say get the same file from CUBIT and from OCC directly, compare, but follow and adhere to OCC and submit a patch to CUBIT to update their CGM. In my understanding CUBIT gets STEP support via CGM. Specifically these two dev-lists would be better for specific discussions and understanding: 1. OCE dev list: https://groups.google.com/forum/#!forum/oce-dev 2. CUBIT help list:[email protected] == Rajeev Jain Software Development Specialist 1134, Building 240 Mathematics and Computer Science Division Argonne National Laboratory Argonne IL, 60439, USA O: 630-252-3176 Google: rajeeja, Voice: 312-725-3380 == On Tuesday, August 25, 2015 3:54 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov> wrote: I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. At http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided athttp://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web pagehttp://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guide…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edgeshould not be multiplied by the sense of the advanced face. I haven’t finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? From:[email protected] [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov> To: "Jain, Rajeev" <jain(a)mcs.anl.gov> Cc: "cgma-dev(a)mcs.anl.gov" <cgma-dev(a)mcs.anl.gov> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Vander Zee, Evan B. 26 Aug '15

26 Aug '15

I have pushed up my changes to the vanderzee/faceVolSense branch. Should I create a pull request for this branch? At this point I do not follow the convention of having surfaces oriented to return outward-facing normals if there is only one volume. Instead, I updated the code so that if you ask for the face-to-volume sense, then you will get the proper answer – forward if the normal faces outward and reversed if the normal faces inward. Moreover, the facets that are returned from get_graphics agree with the normal vector, i.e., they are oriented to be counterclockwise if you were looking down at the surface from the direction that the normal points toward. In other words, the triangle normal computed by the cross product of v1 – v0 with v2 – v0 would point in the same direction as the surface normal. I think this works in most situations, but I suspect that there are some corner cases that I do not know enough about where this would fail. In particular, I am concerned that merge, imprint, or other cases that make essential use of the bridge_sense may fail. Please let me know if you run across a case where what I’ve described is not the case. If we require support for getting all of the triangles returned from get_graphics to be counterclockwise with respect to normals facing outward from a particular volume, then let’s discuss what an appropriate API would be for supporting that use case. It should be quite easy to implement something like that now, but in my opinion the API would have to include specifying the volume from which you want the triangle normal vectors to face outward. -Evan From: cgma-dev-bounces(a)mcs.anl.gov [mailto:[email protected]] On Behalf Of Vander Zee, Evan B. Sent: Wednesday, August 26, 2015 11:57 AM To: cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 I’ve found the problem. My original diagnosis was incorrect. Here’s what the problem was. For the Cubit-generated bricks I was not traversing the edges in the expected order, so after I set up all of the edge senses properly, some later code was reversing all of the edge senses for the Cubit-generated files. When I changed the code to traverse the edges in the expected order, I pass my modified test_edge_orient for brick_2.stp as well as for a box created inside of CGM and when reading the file that contains the box created inside of CGM. After the latest code change, a new test is failing. This is the point_project test. The way the test is written, it projects a point onto a surface using the closest_point_trimmed method. There are two edges that the point could project onto that are equally close. In the current CGM/OCC implementation, the edge that is chosen depends on the internal ordering of the edges, so it makes sense that my code changes could have flipped the test to choose the other of the two equally close edges. I don’t see any documentation saying that the tie should be broken in a particular fashion, so I plan to change the test to allow projecting the point to either of the equally close edges. Thanks for your help. You should see some commits to my vanderzee/faceVolSense branch later today after I clean up the code a bit. -Evan From: jain(a)mcs.anl.gov<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, August 26, 2015 10:41 AM To: Vander Zee, Evan B.; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Cc: Andrew Davis Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan, I'd say get the same file from CUBIT and from OCC directly, compare, but follow and adhere to OCC and submit a patch to CUBIT to update their CGM. In my understanding CUBIT gets STEP support via CGM. Specifically these two dev-lists would be better for specific discussions and understanding: 1. OCE dev list: https://groups.google.com/forum/#!forum/oce-dev 2. CUBIT help list: cubit-help(a)sandia.gov<mailto:[email protected]> == Rajeev Jain Software Development Specialist 1134, Building 240 Mathematics and Computer Science Division Argonne National Laboratory Argonne IL, 60439, USA O: 630-252-3176 Google: rajeeja, Voice: 312-725-3380 == On Tuesday, August 25, 2015 3:54 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> wrote: I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. At http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided at http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web page http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__s…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edge should not be multiplied by the sense of the advanced face. I haven’t finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]>> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]> You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov<mailto:[email protected]> When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> To: "Jain, Rajeev" <jain(a)mcs.anl.gov<mailto:[email protected]>> Cc: "cgma-dev(a)mcs.anl.gov<mailto:[email protected]>" <cgma-dev(a)mcs.anl.gov<mailto:[email protected]>> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov<mailto:[email protected]>> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov<mailto:[email protected]> ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov<mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Vander Zee, Evan B. 26 Aug '15

26 Aug '15

I’ve found the problem. My original diagnosis was incorrect. Here’s what the problem was. For the Cubit-generated bricks I was not traversing the edges in the expected order, so after I set up all of the edge senses properly, some later code was reversing all of the edge senses for the Cubit-generated files. When I changed the code to traverse the edges in the expected order, I pass my modified test_edge_orient for brick_2.stp as well as for a box created inside of CGM and when reading the file that contains the box created inside of CGM. After the latest code change, a new test is failing. This is the point_project test. The way the test is written, it projects a point onto a surface using the closest_point_trimmed method. There are two edges that the point could project onto that are equally close. In the current CGM/OCC implementation, the edge that is chosen depends on the internal ordering of the edges, so it makes sense that my code changes could have flipped the test to choose the other of the two equally close edges. I don’t see any documentation saying that the tie should be broken in a particular fashion, so I plan to change the test to allow projecting the point to either of the equally close edges. Thanks for your help. You should see some commits to my vanderzee/faceVolSense branch later today after I clean up the code a bit. -Evan From: jain(a)mcs.anl.gov [mailto:[email protected]] Sent: Wednesday, August 26, 2015 10:41 AM To: Vander Zee, Evan B.; cgma-dev(a)mcs.anl.gov Cc: Andrew Davis Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan, I'd say get the same file from CUBIT and from OCC directly, compare, but follow and adhere to OCC and submit a patch to CUBIT to update their CGM. In my understanding CUBIT gets STEP support via CGM. Specifically these two dev-lists would be better for specific discussions and understanding: 1. OCE dev list: https://groups.google.com/forum/#!forum/oce-dev 2. CUBIT help list: cubit-help(a)sandia.gov<mailto:[email protected]> == Rajeev Jain Software Development Specialist 1134, Building 240 Mathematics and Computer Science Division Argonne National Laboratory Argonne IL, 60439, USA O: 630-252-3176 Google: rajeeja, Voice: 312-725-3380 == On Tuesday, August 25, 2015 3:54 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> wrote: I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. At http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided at http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web page http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__s…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edge should not be multiplied by the sense of the advanced face. I haven’t finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]>> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]> You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov<mailto:[email protected]> When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> To: "Jain, Rajeev" <jain(a)mcs.anl.gov<mailto:[email protected]>> Cc: "cgma-dev(a)mcs.anl.gov<mailto:[email protected]>" <cgma-dev(a)mcs.anl.gov<mailto:[email protected]>> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov<mailto:[email protected]>> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov<mailto:[email protected]> ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov<mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by jain＠mcs.anl.gov 26 Aug '15

26 Aug '15

Hi Evan, I'd say get the same file from CUBIT and from OCC directly, compare, but follow and adhere to OCC and submit a patch to CUBIT to update their CGM. In my understanding CUBIT gets STEP support via CGM.Specifically these two dev-lists would be better for specific discussions and understanding:1. OCE dev list: https://groups.google.com/forum/#!forum/oce-dev 2. CUBIT help list: cubit-help(a)sandia.gov ==Rajeev JainSoftware Development Specialist1134, Building 240Mathematics and Computer Science DivisionArgonne National LaboratoryArgonne IL, 60439, USAO: 630-252-3176Google: rajeeja, Voice: 312-725-3380== On Tuesday, August 25, 2015 3:54 PM, "Vander Zee, Evan B." <vanderzee(a)anl.gov> wrote: I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. Athttp://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided at http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web pagehttp://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guide…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edgeshould not be multiplied by the sense of the advanced face. I haven’t finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? From:[email protected] [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov> To: "Jain, Rajeev" <jain(a)mcs.anl.gov> Cc: "cgma-dev(a)mcs.anl.gov" <cgma-dev(a)mcs.anl.gov> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Vander Zee, Evan B. 25 Aug '15

25 Aug '15

I tried bringing the .sat file into Cubit 13.1 and exporting it as an .stp file. The result .stp file is not the same as brick_2.stp, but it is similar. I also tried creating a brick in Cubit 13 and exporting to an .stp file. Then I tried creating a brick in Cubit 14.9 and exporting that to an .stp file. All of these have the same problem with edge orientation in the .stp file, and all of them have the same problem when I test them against my revised test_edge_orient. One way to fix the problem by editing these .stp files is to change the geometry in the .stp file so that all normal vectors in the brick face geometries point outward from the brick. The way these .stp files are written, the normal points outward from the top face of the brick, but points inward from the other five faces of the brick. I have deciphered some of the syntax for an STP file, but not all. The website that has helped me the most, I think, is the NIST website. At http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm there is a STEP analyzer that can create a spreadsheet summary of the entities that are in an STP file. From looking at some sample output of this tool that the website provided at http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx you can at least see the names of the attributes of some of the entities. I had also looked at a couple things on Wikipedia, including the link that Rajeev sent, but I did not find them very helpful. For example, you can see that ADVANCED_FACE is defined from (1) a name, (2) a list of bounds, (3) a face_geometry, and (4) a same_sense attribute. The same_sense attribute identifies the sense relative to any CLOSED_SHELL that the ADVANCED_FACE belongs to, if I am interpreting it correctly. In the .stp files that Cubit writes out for a brick, the bounds list for an ADVANCED_FACE happens to consists of one FACE_OUTER_BOUND, which has an attribute that is an EDGE_LOOP, and the EDGE_LOOP has an edge_list attribute that is a list of ORIENTED_EDGE. Digging down into the entites inside an "oriented edge" and the attributes it has you find that for a Cubit brick the "oriented edge" happens to be a sense together with an edge "curve" defined from two vertices and a line that passes through the two points. The line is defined by a point and a direction vector. I won't bore you with all of the specific entities involved. The key thing to notice is that ORIENTED_EDGE defines the sense of the edge relative to the loop it belongs to, i.e., relative to the face that is bounded by that loop, and the direction vector tells the parametrization of the edge that gives the edge its native orientation. The face geometry in .stp files that Cubit writes out for a brick is a PLANE, which is defined by an AXIS2_PLACEMENT_3D. The spreadsheet tells me that AXIS2_PLACEMENT_3D consists of (1) a name, (2) a location, (3) an axis, and (4) a ref_direction. Based on that and some of my reading of Open Cascade reference documention for Geom_Axis2Placement, as well as what makes sense when looking at the data, I interpret the axis to be a normal vector to the plane, and the ref_direction to be a direction vector within the plane, probably in the direction of the u parameter, though I'm not sure yet whether that matters. The axis/normal vector defines the native orientation of the plane so that we know what "counterclockwise" or "to the left of the edge" means and can interpret the same_sense attribute of the advanced face. Open Cascade clearly states that it supports STEP, as documented at the web page http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__s…, and appears to do a good job of supporting it. We are using their STEPControl_Reader in the import_solid_model method in OCCQueryEngine.cpp to read .stp files into an OCC geometry model. The issue appears to be whether the sense in an ORIENTED_EDGE should be multiplied by the sense in an ADVANCED_FACE. In the file written by Cubit, the sense of the oriented edge is multiplied by the sense of the ADVANCED_FACE, but the way that it is being interpreted by OCC, it seems that the sense of the oriented edge should not be multiplied by the sense of the advanced face. I haven't finished researching how OCC interprets the ADVANCED_FACE and its sense when it reads STEP format, so I suppose that there could be a disconnect there. -Evan From: Grindeanu, Iulian R. Sent: Tuesday, August 25, 2015 12:48 PM To: Andrew Davis; cgma-dev(a)mcs.anl.gov Cc: Vander Zee, Evan B. Subject: RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov<mailto:[email protected]> [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov<mailto:[email protected]> Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]>> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]> You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov<mailto:[email protected]> When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> To: "Jain, Rajeev" <jain(a)mcs.anl.gov<mailto:[email protected]>> Cc: "cgma-dev(a)mcs.anl.gov<mailto:[email protected]>" <cgma-dev(a)mcs.anl.gov<mailto:[email protected]>> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov<mailto:[email protected]>> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov<mailto:[email protected]> ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov<mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] CGM brick orientation test
by jain＠mcs.anl.gov 25 Aug '15

25 Aug '15

Found this after some searches:https://en.wikipedia.org/wiki/ISO_10303http://docs.mcneel.com/rhin… ==Rajeev JainSoftware Development Specialist1134, Building 240Mathematics and Computer Science DivisionArgonne National LaboratoryArgonne IL, 60439, USAO: 630-252-3176Google: rajeeja, Voice: 312-725-3380== On Tuesday, August 25, 2015 11:55 AM, "Vander Zee, Evan B." <vanderzee(a)anl.gov> wrote: Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Grindeanu, Iulian R. 25 Aug '15

25 Aug '15

hmmm, I don't remember how I got the sat file. Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp ) will you see the same problems in your test? Evan, did you decipher the orientation issues/ syntax in an STP file? what websites did you find? standards, etc? What do OCC/OCE say about stp format? Is it fully supported? What do we do when we read stp with our OCC engine? ________________________________ From: cgma-dev-bounces(a)mcs.anl.gov [cgma-dev-bounces(a)mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis(a)gmail.com] Sent: Tuesday, August 25, 2015 12:06 PM To: cgma-dev(a)mcs.anl.gov Subject: Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3 Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]>> wrote: Send cgma-dev mailing list submissions to cgma-dev(a)mcs.anl.gov<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev or, via email, send a message with subject or body 'help' to cgma-dev-request(a)mcs.anl.gov<mailto:[email protected]> You can reach the person managing the list at cgma-dev-owner(a)mcs.anl.gov<mailto:[email protected]> When replying, please edit your Subject line so it is more specific than "Re: Contents of cgma-dev digest..." Today's Topics: 1. CGM brick orientation test (Vander Zee, Evan B.) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2015 16:54:28 +0000 From: "Vander Zee, Evan B." <vanderzee(a)anl.gov<mailto:[email protected]>> To: "Jain, Rajeev" <jain(a)mcs.anl.gov<mailto:[email protected]>> Cc: "cgma-dev(a)mcs.anl.gov<mailto:[email protected]>" <cgma-dev(a)mcs.anl.gov<mailto:[email protected]>> Subject: [cgma-dev] CGM brick orientation test Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov<mailto:[email protected]>> Content-Type: text/plain; charset="us-ascii" Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov<mailto:[email protected]> ------------------------------ _______________________________________________ cgma-dev mailing list cgma-dev(a)mcs.anl.gov<mailto:[email protected]> https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev End of cgma-dev Digest, Vol 81, Issue 3 ***************************************

1 0

Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3
by Andrew Davis 25 Aug '15

25 Aug '15

Hi Evan My assumption would be that it was converted via Cubit from the equivalent *.sat file. Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. However, the stp is older than the sat by about a year Andy On Tue, Aug 25, 2015 at 12:00 PM, <cgma-dev-request(a)mcs.anl.gov> wrote: > Send cgma-dev mailing list submissions to > cgma-dev(a)mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev > or, via email, send a message with subject or body 'help' to > cgma-dev-request(a)mcs.anl.gov > > You can reach the person managing the list at > cgma-dev-owner(a)mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cgma-dev digest..." > > > Today's Topics: > > 1. CGM brick orientation test (Vander Zee, Evan B.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Aug 2015 16:54:28 +0000 > From: "Vander Zee, Evan B." <vanderzee(a)anl.gov> > To: "Jain, Rajeev" <jain(a)mcs.anl.gov> > Cc: "cgma-dev(a)mcs.anl.gov" <cgma-dev(a)mcs.anl.gov> > Subject: [cgma-dev] CGM brick orientation test > Message-ID: <553D5F34658FB846ACEA00D6140EAC6897ADB09F(a)PAYTON.anl.gov> > Content-Type: text/plain; charset="us-ascii" > > Do you know the source of the file itaps/brick_2.stp in the CGM > repository? It looks to me like the edges in the file have improper edge > orientations. > > I have some local changes to CGM that, I thought, fix the face-to-volume > sense bug. I am testing the changes in various ways and learning more > about OCC and CGM. This version of itaps/brick_2.stp has been used by the > test_edge_orient test in the itaps directory. I disabled the test > previously in my edgeFaceSense branch when I fixed an edge-to-face > orientation problem. I am working on rewriting the test now so that it > properly tests the face-to-volume sense and the edge-to-face sense for both > OCC and ACIS. > > I have the face-to-volume part of the test working fine for OCC now, but > my revised edge orientation part of the test is failing. This part of the > test tests edge orientation after reading the itaps/brick_2.stp file. When > I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the > brick from file, my revised edge orientation part of the test passes. If I > save that brick to a file, then I can also read the file I've saved, and > the edge orientation part of the test passes. > > I looked at the brick_2.stp file and my human-readable interpretation is > that the edge orientations are encoded incorrectly. I think I could > correct it by hand within the file by changing the orientation of some of > the oriented edges at entities 106 through 144. I want to know whether > it's okay to do that or the STEP file came from some source outside of CGM > that we need to be able to support. The brick that CGM writes out after > iGeom_createBrick is represented quite differently from the way the one in > itaps/brick_2.stp is represented. > > It would help me if I could get a reference for the geometric STEP > entities. I have pieced together a few things through Internet searches, > but I have not been able to find good reference documentation for the parts > of STEP that are used by CGM. Do you know of any? > > -Evan > vanderzee(a)anl.gov > > > ------------------------------ > > _______________________________________________ > cgma-dev mailing list > cgma-dev(a)mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev > > > End of cgma-dev Digest, Vol 81, Issue 3 > *************************************** >

1 0

CGM brick orientation test
by Vander Zee, Evan B. 25 Aug '15

25 Aug '15

Do you know the source of the file itaps/brick_2.stp in the CGM repository? It looks to me like the edges in the file have improper edge orientations. I have some local changes to CGM that, I thought, fix the face-to-volume sense bug. I am testing the changes in various ways and learning more about OCC and CGM. This version of itaps/brick_2.stp has been used by the test_edge_orient test in the itaps directory. I disabled the test previously in my edgeFaceSense branch when I fixed an edge-to-face orientation problem. I am working on rewriting the test now so that it properly tests the face-to-volume sense and the edge-to-face sense for both OCC and ACIS. I have the face-to-volume part of the test working fine for OCC now, but my revised edge orientation part of the test is failing. This part of the test tests edge orientation after reading the itaps/brick_2.stp file. When I create a 2 x 2 x 2 brick using iGeom_createBrick rather than reading the brick from file, my revised edge orientation part of the test passes. If I save that brick to a file, then I can also read the file I've saved, and the edge orientation part of the test passes. I looked at the brick_2.stp file and my human-readable interpretation is that the edge orientations are encoded incorrectly. I think I could correct it by hand within the file by changing the orientation of some of the oriented edges at entities 106 through 144. I want to know whether it's okay to do that or the STEP file came from some source outside of CGM that we need to be able to support. The brick that CGM writes out after iGeom_createBrick is represented quite differently from the way the one in itaps/brick_2.stp is represented. It would help me if I could get a reference for the geometric STEP entities. I have pieced together a few things through Internet searches, but I have not been able to find good reference documentation for the parts of STEP that are used by CGM. Do you know of any? -Evan vanderzee(a)anl.gov

1 0