<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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
<a href="http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm">http://www.nist.gov/el/msid/infotest/step-file-analyzer.cfm</a> 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 <a href="http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx">
http://www.nist.gov/el/msid/infotest/upload/STEP-File-Analyzer_stp.xlsx</a> 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Open Cascade clearly states that it supports STEP, as documented at the web page
<a href="http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__step.html">
http://www.opencascade.org/doc/occt-6.9.0/overview/html/occt_user_guides__step.html</a>, 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">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 <i>is</i> 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
<i>should not be</i> 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">-Evan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Grindeanu, Iulian R.
<br>
<b>Sent:</b> Tuesday, August 25, 2015 12:48 PM<br>
<b>To:</b> Andrew Davis; cgma-dev@mcs.anl.gov<br>
<b>Cc:</b> Vander Zee, Evan B.<br>
<b>Subject:</b> RE: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">hmmm,<br>
I don't remember how I got the sat file.<br>
<br>
Maybe we could import the stp file again in cubit, "regularize" or something, and export again (with cubit 14, as an stp )<br>
will you see the same problems in your test?<br>
<br>
Evan, did you decipher the orientation issues/ syntax in an STP file? <br>
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?
<br>
<br>
<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div id="divRpF368227">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">
<a href="mailto:cgma-dev-bounces@mcs.anl.gov">cgma-dev-bounces@mcs.anl.gov</a> [cgma-dev-bounces@mcs.anl.gov] on behalf of Andrew Davis [andrewdavis.davis@gmail.com]<br>
<b>Sent:</b> Tuesday, August 25, 2015 12:06 PM<br>
<b>To:</b> <a href="mailto:cgma-dev@mcs.anl.gov">cgma-dev@mcs.anl.gov</a><br>
<b>Subject:</b> Re: [cgma-dev] cgma-dev Digest, Vol 81, Issue 3</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">Hi Evan <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">My assumption would be that it was converted via Cubit from the equivalent *.sat file.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Looking at git blame its from Hong-Jun Kim (stp), the sat is from Iulian. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">However, the stp is older than the sat by about a year<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Andy<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">On Tue, Aug 25, 2015 at 12:00 PM, <<a href="mailto:cgma-dev-request@mcs.anl.gov" target="_blank">cgma-dev-request@mcs.anl.gov</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Send cgma-dev mailing list submissions to<br>
<a href="mailto:cgma-dev@mcs.anl.gov" target="_blank">cgma-dev@mcs.anl.gov</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev" target="_blank">
https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cgma-dev-request@mcs.anl.gov" target="_blank">cgma-dev-request@mcs.anl.gov</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cgma-dev-owner@mcs.anl.gov" target="_blank">cgma-dev-owner@mcs.anl.gov</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cgma-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. CGM brick orientation test (Vander Zee, Evan B.)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 25 Aug 2015 16:54:28 +0000<br>
From: "Vander Zee, Evan B." <<a href="mailto:vanderzee@anl.gov" target="_blank">vanderzee@anl.gov</a>><br>
To: "Jain, Rajeev" <<a href="mailto:jain@mcs.anl.gov" target="_blank">jain@mcs.anl.gov</a>><br>
Cc: "<a href="mailto:cgma-dev@mcs.anl.gov" target="_blank">cgma-dev@mcs.anl.gov</a>" <<a href="mailto:cgma-dev@mcs.anl.gov" target="_blank">cgma-dev@mcs.anl.gov</a>><br>
Subject: [cgma-dev] CGM brick orientation test<br>
Message-ID: <<a href="mailto:553D5F34658FB846ACEA00D6140EAC6897ADB09F@PAYTON.anl.gov" target="_blank">553D5F34658FB846ACEA00D6140EAC6897ADB09F@PAYTON.anl.gov</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
-Evan<br>
<a href="mailto:vanderzee@anl.gov" target="_blank">vanderzee@anl.gov</a><br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cgma-dev mailing list<br>
<a href="mailto:cgma-dev@mcs.anl.gov" target="_blank">cgma-dev@mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/cgma-dev</a><br>
<br>
<br>
End of cgma-dev Digest, Vol 81, Issue 3<br>
***************************************<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>