[cgma-dev] Continuing discussion of iGeom handling of RefVolume vs Body

[shriwise]

Hi all,

 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.

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.

_*Using RefVolumes Exclusively*_
As it currently stands in specification, in the iGeom interface there is 
no notion of a body or, perhaps more importantly, an Entity which 
/contains/ 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:

1) Only return bodies as EntitySets which contain the appropriate 
Entities (these relationships being set within the functions being called.)
     - This would require

2) Return arrays of Entities from functions when appropriate, along with 
an indicator of the array size.

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.

_*Using Bodies Exclusively*_
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.

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.

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.

Cheers,

Patrick
On 01/29/2015 03:17 PM, Paul Wilson wrote:
> Hello,
>
> There has been some discussion in a pull request 
> <https://bitbucket.org/fathomteam/cgm/pull-request/8/igeom-updates> 
> that I thought would be better brought to the mailing list.
>
> 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.
>
> 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.
>
> So.... perhaps we need to only deal with Body in the iGeom interface.  
> Perhaps Patrick can offer some of the downsides to this approach?
>
> Paul
>
> -- 
> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
> Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal:http://bit.ly/pphw-cal
> Professor, Engineering Physics. ~http://cnerg.engr.wisc.edu
> Faculty Director, Advanced Computing Infrastructure ~http://aci.wisc.edu		

-- 
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20150130/06cdf700/attachment.html>