<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Adding to this discussion, I spoke with Tim Tautges this morning and
he had a few thoughts to add. <br>
<br>
He prefers the option in which an iGeomEntityHandle pointer and an
integer for the number of entities returned are used to indicate the
result of these boolean operations we have been discussing. His
reasoning is that in iGeom EntitySets were intended to indicate the
state of the geometry to the user rather than for use as a container
of objects. He also saw it working better with the current c
implementation on the backend of this interface. <br>
<br>
Just wanted to throw that into the mix for future reference. <br>
<br>
Cheers, <br>
<br>
Patrick <br>
<br>
<div class="moz-cite-prefix">On 02/09/2015 07:59 AM, Patrick
Shriwise wrote:<br>
</div>
<blockquote cite="mid:54D8BD31.7070705@wisc.edu" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi all, <br>
<br>
Are there any other thoughts on this? Or ideas on the proper steps
forward for the iGeom implementation in CGM?<br>
<br>
Cheers,<br>
<br>
Patrick<br>
<br>
<br>
<div class="moz-cite-prefix">On 02/02/2015 12:43 PM, Patrick
Shriwise wrote:<br>
</div>
<blockquote cite="mid:54CFC55E.4030202@wisc.edu" type="cite"> 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>
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 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 moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:cgma-dev-bounces@mcs.anl.gov">cgma-dev-bounces@mcs.anl.gov</a>
[<a moz-do-not-send="true"
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>
</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>
</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>