<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=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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<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"> cgma-dev-bounces@mcs.anl.gov [mailto:cgma-dev-bounces@mcs.anl.gov]
<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 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 href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a><o:p></o:p></pre>
<pre>Professor, Engineering Physics. ~ <a href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a><o:p></o:p></pre>
<pre>Faculty Director, Advanced Computing Infrastructure ~ <a 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>
</body>
</html>