<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
<u><b>Using RefVolumes Exclusively</b></u><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>
<u><b>Using Bodies Exclusively</b></u><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 <br>
<div class="moz-cite-prefix">On 01/29/2015 03:17 PM, Paul Wilson
wrote:<br>
</div>
<blockquote cite="mid:54CAA351.2040407@wisc.edu" type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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>
<pre class="moz-signature" cols="72">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure ~ <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://aci.wisc.edu">http://aci.wisc.edu</a> </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>