<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Evan, <br>
<br>
As to 2). I completely agree and I think if I'm reading it correctly
its aligning with the second of my two purposed solutions in the
prior email. <br>
<br>
1) does seem to add a complication or two. I'm glad you brought it
up! <br>
<br>
I don't know much about how these bodies fit into the hierarchy of
CGM, but naively it seems that if they are still treated as
RefVolumes then operations on these sheets could be handled as usual
in CGM behind the iGeom interface. For the user, it might be good to
add something in iGeom which will notify them that a sheet
body/volume has been returned if it is a possibility in the function
they have called. What it looks like to me from this code in
Body.cpp<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
CubitBoolean Body::is_sheet_body()<br>
{<br>
DLIList<RefVolume*> volumes;<br>
ref_volumes(volumes);<br>
while (volumes.size())<br>
if (!volumes.pop()->is_sheet())<br>
return CUBIT_FALSE;<br>
return CUBIT_TRUE;<br>
}<br>
<br>
is that sheet bodies are still in fact treated as RefVolumes.
However after looking at some of the OCC code, sheets in OCC come
back as OCCSurfaces. I'm assuming that these are then translated to
RefVolumes in the context of CGM, but I lack the expertise to know
exactly. Does anyone have an exact answer to this?<br>
<br>
If we can still treat RefVolumes which are sheets in the same way as
other RefVolumes then I think returning only RefVolumes is still a
valid option. If we find that this is not the case or that it will
obscure the interface by causing certain operations to be
compromised, then we might have an entirely different problem to
deal with. <br>
<br>
Cheers, <br>
<br>
Patrick <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/30/2015 12:20 PM, Vander Zee,
Evan B. wrote:<br>
</div>
<blockquote
cite="mid:553D5F34658FB846ACEA00D6140EAC688BD74790@PAYTON.anl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";
color:black;}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:990065870;
mso-list-type:hybrid;
mso-list-template-ids:-300136328 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">There
are two additional things that we might want to consider in
this discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><span
style="mso-list:Ignore">1)<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">When
are bodies that CGM is passing through the iGeom interface
allowed to be “sheet bodies?” In other words, when should
we be able to pass what are essentially 2-dimensional
entities through the iGeom interface?<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><span
style="mso-list:Ignore">2)<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">The
input path of iGeom is a consideration as well as the output
side. We can assume, I think, that the only entity handles
a user passes into methods through the iGeom interface are
entity handles that have been accessed through the iGeom
interface. If we want to allow operations that apply to
multiple volumes, but we never pass back entity handles that
refer to multiple-volume bodies, then we should make sure
that the interface includes methods that support passing in
a list of entities or an entity set. For example, the
interface already supports subtract with entity set
arguments as well as with entity handles.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">I
think that with a little documentation, we could expect
users to be responsible for cleaning up single-entity entity
sets that are returned from operations that could in some
cases return multiple volumes. However, making it easier to
use and not expecting a lot of the user is often the better
path.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">These
are just a few comments from a guy who’s relatively new to
CGM. Please continue the discussion with comments from more
experienced developers.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">-Evan</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><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>
<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";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
<a class="moz-txt-link-abbreviated" href="mailto:cgma-dev-bounces@mcs.anl.gov">cgma-dev-bounces@mcs.anl.gov</a>
[<a class="moz-txt-link-freetext" href="mailto:cgma-dev-bounces@mcs.anl.gov">mailto:cgma-dev-bounces@mcs.anl.gov</a>]
<b>On Behalf Of </b>shriwise<br>
<b>Sent:</b> Friday, January 30, 2015 9:15 AM<br>
<b>To:</b> Paul Wilson; CGMA Development<br>
<b>Subject:</b> Re: [cgma-dev] Continuing discussion of
iGeom handling of RefVolume vs Body<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><br>
<br>
Hi all,<br>
<br>
From an iGeom perspective, I'm not sure that using bodies is a
bad thing... The real issue to me is the mix currently being
used. It has been shown to cause problems in iRel. In any
case, I think that we should move entirely to one or the
other.
<br>
<br>
The real issue to me is that outside of the user's knowledge
of the geometry, they can't be sure if the body they are
getting from UniteEnts, IntersectEnts, etc. contains disjoint
volumes or not.
<br>
<br>
<b><u>Using RefVolumes Exclusively</u></b><br>
As it currently stands in specification, in the iGeom
interface there is no notion of a body or, perhaps more
importantly, an Entity which
<i>contains</i> other entities. There are only Entities and
EntitySets. The point being that returning a recast cgm Body
as an Entity from iGeom simply shouldn't be allowed as it
breaks established conventions of iGeom unless we do one of
two things:<br>
<br>
1) Only return bodies as EntitySets which contain the
appropriate Entities (these relationships being set within the
functions being called.)<br>
- This would require <br>
<br>
2) Return arrays of Entities from functions when appropriate,
along with an indicator of the array size.<br>
<br>
Either way, a proper iGeom implementation will require a bit
of a deeper look at any function that currently returns a Body
to determine the proper way to handle this. For example, the
createSphere function should really return a single RefVolume
as the body created from this process wouldn't be expected to
have more than one volume. However, I think that other
functions like uniteEnts and so on will require something like
1) or 2) above.
<br>
<br>
<b><u>Using Bodies Exclusively</u></b><br>
All this being said about RefVolumes, it would certainly be
possible to always return Bodies from iGeom for dimension 3
entities, but as I mentioned above I think this should always
be done using EntitySets. This implementation would be less
clean as iGeom models would then perhaps contain many
EntitySets most of which really only contain one entity. The
user would then have to retrieve their created entities proper
by querying the EntitySets. It adds an unnecessary level of
abstraction and might cloud the user's idea of what EntitySets
are intended for.<br>
<br>
One last thing I'll say in favor of using RefVolumes
exclusively but returning lists is that it adds clarity to the
interface. By having boolean functions like uniteEnts and
others return lists or EntitySets, it will imply to the user
that iGeom is capable of doing these operations in the case of
disjointed volumes and that they may be getting multiple
volume entities back from these functions. If we were to
return bodies only, it then becomes ambiguous (and perhaps
confusing to the user) as to whether or not any function
called is returning one or more volumes. <br>
<br>
That's my take. Apologies for the lack of insight in the
changes found in the current PR. The situation is not as
simple as I'd initially thought.
<br>
<br>
Cheers, <br>
<br>
Patrick <o:p></o:p></p>
<div>
<p class="MsoNormal">On 01/29/2015 03:17 PM, Paul Wilson
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hello,<br>
<br>
There has been some discussion in a <a
moz-do-not-send="true"
href="https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates">
pull request</a> that I thought would be better brought to
the mailing list.<br>
<br>
This was initially motivated by the realization that iGeom
was inconsistent in returning a RefVolume vs a Body in
different calls. Thus, two entity handles that referred to
the same volume in space would not be detected as the same
volume.<br>
<br>
Faced with two choices - refer only to RefVolumes or refer
only to Body's - we settled on referring only to refVolume's
in the iGeom interface. However, this breaks the ability to
refer to a Body such as my be returned by uniting two
volumes that are disjoint - which is part of the interface.<br>
<br>
So.... perhaps we need to only deal with Body in the iGeom
interface. Perhaps Patrick can offer some of the downsides
to this approach?<br>
<br>
Paul<br>
<br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --<o:p></o:p></pre>
<pre>Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a><o:p></o:p></pre>
<pre>Professor, Engineering Physics. ~ <a moz-do-not-send="true" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a><o:p></o:p></pre>
<pre>Faculty Director, Advanced Computing Infrastructure ~ <a moz-do-not-send="true" href="http://aci.wisc.edu">http://aci.wisc.edu</a> <o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Patrick C. Shriwise<o:p></o:p></pre>
<pre>Research Assistant<o:p></o:p></pre>
<pre>University of Wisconsin - Madison<o:p></o:p></pre>
<pre>Engineering Research Building - Rm. 428<o:p></o:p></pre>
<pre>1500 Engineering Drive<o:p></o:p></pre>
<pre>Madison, WI 53706<o:p></o:p></pre>
<pre>(608) 446-8173<o:p></o:p></pre>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173
</pre>
</body>
</html>