<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Rajeev,<br>
<br>
Thanks for the response. I guess it's still not clear what the
expected behavior should be when copying an entity in iGeom. Should
it copy some/none/all of the tags to the new entity? Is there a
standard for what gets copied?<br>
<br>
Paul<br>
<br>
<div class="moz-cite-prefix">On 07/15/2014 08:26 PM, Rajeev Jain
wrote:<br>
</div>
<blockquote
cite="mid:1405473998.69092.YahooMailNeo@web122002.mail.ne1.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff; font-family:lucida
console, sans-serif;font-size:10pt">
<div><span>Sorry, I missed this email.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; font-style: normal;
background-color: transparent;"><span>Yes, you are right. It
is for OCC based meshing. The test names volumes/surfs etc
and then tries to retrieve them.</span></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; font-style: normal;
background-color: transparent;">You can ignore the test case
as we started working on developing other missing pieces for
OCC geometry based meshing in MeshKit. When entities are
copied the names can be copied with some an additional letter
word under some convention. </div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; font-style: normal;
background-color: transparent;">Ex. CUBIT uses vol 1 named as
mysteel when copied the new vol 2 is called mysteel@a etc.</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; font-style: normal;
background-color: transparent;"><span><br>
</span></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
'lucida console', sans-serif; font-style: normal;
background-color: transparent;"><span>Rajeev</span></div>
<div><br>
</div>
<div style="font-family: 'lucida console', sans-serif;
font-size: 10pt;">
<div style="font-family: HelveticaNeue, 'Helvetica Neue',
Helvetica, Arial, 'Lucida Grande', sans-serif; font-size:
12pt;">
<div dir="ltr">
<hr size="1"> <font face="Arial" size="2"> <b><span
style="font-weight:bold;">From:</span></b> shriwise
<a class="moz-txt-link-rfc2396E" href="mailto:shriwise@wisc.edu"><shriwise@wisc.edu></a><br>
<b><span style="font-weight: bold;">To:</span></b> Paul
Wilson <a class="moz-txt-link-rfc2396E" href="mailto:wilsonp@engr.wisc.edu"><wilsonp@engr.wisc.edu></a>; "Jain, Rajeev"
<a class="moz-txt-link-rfc2396E" href="mailto:jain@mcs.anl.gov"><jain@mcs.anl.gov></a>; CGMA Development
<a class="moz-txt-link-rfc2396E" href="mailto:cgma-dev@mcs.anl.gov"><cgma-dev@mcs.anl.gov></a> <br>
<b><span style="font-weight: bold;">Sent:</span></b>
Tuesday, July 15, 2014 10:29 AM<br>
<b><span style="font-weight: bold;">Subject:</span></b>
Re: [cgma-dev] Inconsistency in getEntities for iGeom
interface. Causes problems in iRel.<br>
</font> </div>
<div class="y_msg_container"><br>
<div id="yiv4055611019">
<div>
Bump. <br>
<br>
<div class="yiv4055611019moz-cite-prefix">On
07/11/2014 08:15 PM, Paul Wilson wrote:<br>
</div>
<blockquote type="cite">Rajeev,<br>
<br>
You are mentioned in the git logs as the inspiration
for the copy_attrib test that Patrick mentioned. (a
few years ago)<br>
<br>
I wonder if you have any thoughts on what the
purpose and/or requirements are for this
capability? You probably needed it for RGG based on
OCC?<br>
<br>
Paul<br>
<br>
<div class="yiv4055611019moz-cite-prefix">On
07/11/2014 07:21 PM, Patrick Shriwise wrote:<br>
</div>
<blockquote type="cite">Hi all, <br>
<br>
I'm currently working on the changes to iGeom that
Paul previously proposed. I've hit one test when
built with OCC (copy_attrib) that suggests that
tags are expected to be copied along with an
entity when using iGeom functions like copyEnt or
subtractEnt. Is this the case? Are these specifc
tags that are supposed to be copied if they exist
on the original entity?<br>
<br>
Also to be clear this has become an issue because
for volume entities we now use the RefVolume to
get the volume Body and make a copy of that body
using the GeometryModifyTool. The Body we make a
copy of does not have the tags associated with the
RefVolume. As a result the new Body and the
corresponding RefVolumethat we return from the
function does not have the original tags.
<br>
<br>
These tags can be transferred to the new entity
before leaving the function of course, but we're
looking for the proper way to handle this
situation. Mainly it would be good to know if
there is a particular tag or tags that should be
copied over to new entity upon it's creation. <br>
<br>
Cheers, <br>
<br>
Patrick <br>
<br>
<br>
<div class="yiv4055611019moz-cite-prefix">On
06/23/2014 03:06 PM, Paul Wilson wrote:<br>
</div>
<blockquote type="cite">Hi everyone,<br>
<br>
Patrick and I have discussed this and have come
up with the following proposal for a revision of
how iGeom_CGMA handles RefVolumes and Body's.<br>
<ol>
<li>All references to iBase_REGION will refer
only to entities of type RefVolume in CGM.
</li>
<li>All entities that are returned by iGeom
will be RefEntities and not CubitEntities
</li>
<li>At the time of loading file, based on an
option based to iGeom_load(), all entities
of type Body in CGM that contain more than a
single volume, will be converted to
RefGroup's and tagged to distinguish them
from the original RefGroup's
</li>
</ol>
<div>The last of these may be subject to the
most conversation, but it seemed like a useful
approach to use because it:<br>
</div>
<ul>
<li>had little to no effect on the API of
iGeom </li>
<li>preserves access to CGM/ACIS bodies </li>
<li>is the least intrusive in the
implementation of iGeom_CGMA </li>
</ul>
<div>If a user does NOT pass in the option (e.g.
"CONVERT_BODY_TO_GROUP"), then no bodies will
be accessible through iGeom. If a user does
pass in this option, any call to
iGeom_getEntSets will return both the original
RefGroups and the additional RefGroups that
were generated automatically from Bodies. It
will be up to the user to filter between them
using the available tag.
<br>
</div>
<div>Finally, since every RefVolume in ACIS
always has a Body in which it is a member, it
seems best to only convert Bodies that contain
>1 RefVolume to avoid creating far more
RefGroups than necessary.<br>
</div>
<div>We'd like to embark on these changes soon,
but welcome any comments or feedback. I'm
sure we've missed something!<br>
</div>
<div>Paul<br>
</div>
<br>
<div class="yiv4055611019moz-cite-prefix">On
06/17/2014 09:00 AM, Jane Hu wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">So, I will add RefVolume to the
return list of iGeom_get_adjacent_entities()
as the result of the discussion.
<div><br>
</div>
<div>CubitEntity only has derived classes of
RefEntity
and CubitCoordinateSystem, iGeom_CGMA.cc
only uses RefEntity as instance of the
object. </div>
<div><br>
</div>
<div>Jane</div>
</div>
<div class="yiv4055611019gmail_extra"><br>
<br>
<div class="yiv4055611019gmail_quote">On
Mon, Jun 16, 2014 at 11:35 AM, Jane Hu <span
dir="ltr">
<<a moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:janejhu@gmail.com"
target="_blank"
href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>></span>
wrote:<br>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex;">
<div dir="ltr">See comments below...<br>
<div class="yiv4055611019gmail_extra"><br>
<br>
<div
class="yiv4055611019gmail_quote">
<div class="yiv4055611019">On Mon,
Jun 16, 2014 at 10:22 AM, Paul
Wilson <span dir="ltr"><<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:wilsonp@engr.wisc.edu"
target="_blank"
href="mailto:wilsonp@engr.wisc.edu">wilsonp@engr.wisc.edu</a>></span>
wrote:<br>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div>Hi Jane,<br>
<br>
I think this needs a
thorough review! Patrick
and I hunted through
iGeom_CGMA and found some
inconsistencies in a few
places.<br>
<br>
First, there is an
inconsistency between
returning pointers to
RefEntity and pointers to
CubitEntity. This is
probably less important, but
should probably be resolved
in any change.<br>
</div>
</blockquote>
<div> </div>
</div>
<div>I see RefEntity is inherited
from CubitEntity, and
CubitEntity is a pure virtual
class. So even you got pointers
to CubitEntity, you have to
instantiate it to RefEntity
objects.</div>
<div class="yiv4055611019">
<div> </div>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div><br>
Second, there are places
where the geometry is
queried for entities of
dimension=3 (returning
RefVolumes) and places where
the geometry is queried for
entities of
type=iGeom_REGION (== Body).<br>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>In this case, I can return
both bodies and refvolumes, so
after user gets the refentity
list back, he can cast to see if
they are bodies or refvolumes,
and choose to keep what ever he
needs.</div>
<div>
<div class="yiv4055611019h5">
<div> </div>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div><br>
This means that 2 calls
into the interface that
should resolve to the same
entity may not do so for
both reasons.<br>
<br>
All of this is related to
the fundamental difference
between the iGeom types
(equivalent to vertex,
edge, face, volume) and
the CGM/ACIS types
(equiavlent to vertex,
edge, face, volume,
body). I think Tim's
suggestion is the best,
but will require some
substantial effort.<span><font
color="#888888"><br>
<br>
Paul</font></span>
<div>
<div><br>
<br>
<div>On 06/16/2014
10:14 AM, Jane Hu
wrote:<br>
</div>
<blockquote
type="cite">
<div dir="ltr">I see
in iGeom_CGMA.cc
file,
function iGeom_get_adjacent_entities,
if asks for 3-D
refentities, it
returns body list.
In CGM, bodies are
not necessary to
be 3-D entities,
it may contain
single surface or
shell. Should we
change the return
to be only
refvolumes which
are 3-D entities
(I prefer this,
makes more sense)?
Or I can return
both bodies and
refvolumes in the
returned refentity
list. Depending on
your user case, I
can return one of
the two choices.
<div><br>
</div>
<div>Jane</div>
</div>
<div
class="yiv4055611019gmail_extra"><br>
<br>
<div
class="yiv4055611019gmail_quote">On
Mon, Jun 16,
2014 at 9:32 AM,
Jane Hu <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:janejhu@gmail.com" target="_blank"
href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>></span>
wrote:<br>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div dir="ltr">Yes,
it returns a
list of
refVolume's
which are
RefEntities.<span><font
color="#888888">
<div><br>
</div>
<div>Jane</div>
</font></span></div>
<div>
<div>
<div
class="yiv4055611019gmail_extra"><br>
<br>
<div
class="yiv4055611019gmail_quote">On
Sun, Jun 15,
2014 at 11:55
PM, Patrick
Shriwise <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:shriwise@wisc.edu" target="_blank"
href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>></span>
wrote:<br>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div>
<div>Hi Jane, </div>
<div><br>
</div>
<div>Will the
ref_volumes()
method return
RefEntities? </div>
<span><font
color="#888888">
<div><br>
</div>
<div>Patrick</div>
</font></span>
<div>
<div>
<div><br>
On Jun 15,
2014, at 3:56
PM, Jane Hu
<<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:janejhu@gmail.com" target="_blank"
href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote
type="cite">
<div>
<div dir="ltr">Look
at line 6454,
if you have
body's
pointer,
directly call
ref_volumes()
will work.
It's not an
iGeom
interface
function, but
you can access
it in iGeom.
<div><br>
</div>
<div>Good
luck!</div>
<div><br>
</div>
<div>Jane</div>
</div>
<div
class="yiv4055611019gmail_extra"><br>
<br>
<div
class="yiv4055611019gmail_quote">On
Sat, Jun 14,
2014 at 8:55
AM, Patrick
Shriwise <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:shriwise@wisc.edu" target="_blank"
href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>></span>
wrote:<br>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div>Hi Jane,
<br>
<br>
I looked
around for
this but
didn't see it,
is there a
specific
line/function
you were
thinking of?
Good to know
the ref_volume
information is
so easy to get
to, but it
doesn't seem
that its part
of the iGeom
interface. The
issue being
that there's
no way to
access a
body's volumes
via iGeom. <br>
<br>
Cheers, <br>
<br>
Patrick <br>
<div>
<div>
<div>On
06/13/2014
11:26 PM, Jane
Hu wrote:<br>
</div>
<blockquote
type="cite">
<div dir="ltr"><br>
<div
class="yiv4055611019gmail_extra"><br>
<div
class="yiv4055611019gmail_quote">
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div><br>
<br>
Is there a
way to get
volumes within
bodies via
iGeom?</div>
</blockquote>
<div><br>
</div>
<div>See
example in
iGeom_CGMA.cc,
body->ref_volumes(volumes).</div>
<div><br>
</div>
<div>Jane</div>
<blockquote
class="yiv4055611019gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;">
<div><span><font
color="#888888"><br>
<pre>--
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
<a moz-do-not-send="true" rel="nofollow" href="">(608) 446-8173</a>
</pre>
</font></span></div>
</blockquote>
</div>
<br>
<br
clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst.
Researcher<br>
Dept. of
Engineering
Physics<br>
UW @ Madison<br>
<br>
"And we know
that for those
who love God,
that is, for
those who are
called
according to
his purpose,
all things are
working
together for
good." (Romans
8:28)
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br
clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst.
Researcher<br>
Dept. of
Engineering
Physics<br>
UW @ Madison<br>
<br>
"And we know
that for those
who love God,
that is, for
those who are
called
according to
his purpose,
all things are
working
together for
good." (Romans
8:28)
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br
clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst.
Researcher<br>
Dept. of
Engineering
Physics<br>
UW @ Madison<br>
<br>
"And we know
that for those
who love God,
that is, for
those who are
called
according to
his purpose,
all things are
working
together for
good." (Romans
8:28)
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst. Researcher<br>
Dept. of
Engineering
Physics<br>
UW @ Madison<br>
<br>
"And we know that
for those who love
God, that is, for
those who are
called according
to his purpose,
all things are
working together
for good." (Romans
8:28)
</div>
</blockquote>
<br>
</div>
</div>
<div>
<pre>--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ <a moz-do-not-send="true" rel="nofollow" href="">608-263-0807</a> ~ cal: <a moz-do-not-send="true" rel="nofollow" target="_blank" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a moz-do-not-send="true" rel="nofollow" target="_blank" href="http://cnerg.engr.wisc.edu/">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div>
<div class="yiv4055611019h5"><br>
<br clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst. Researcher<br>
Dept. of Engineering Physics<br>
UW @ Madison<br>
<br>
"And we know that for those who
love God, that is, for those who
are called according to his
purpose, all things are working
together for good." (Romans
8:28)
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Jane Hu<br>
<br>
Asst. Researcher<br>
Dept. of Engineering Physics<br>
UW @ Madison<br>
<br>
"And we know that for those who love God,
that is, for those who are called according
to his purpose, all things are working
together for good." (Romans 8:28)
</div>
</blockquote>
<br>
<pre class="yiv4055611019moz-signature">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" rel="nofollow" class="yiv4055611019moz-txt-link-freetext" target="_blank" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a moz-do-not-send="true" rel="nofollow" class="yiv4055611019moz-txt-link-freetext" target="_blank" href="http://cnerg.engr.wisc.edu/">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</blockquote>
<br>
<pre class="yiv4055611019moz-signature">--
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="yiv4055611019moz-signature">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" rel="nofollow" class="yiv4055611019moz-txt-link-freetext" target="_blank" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a moz-do-not-send="true" rel="nofollow" class="yiv4055611019moz-txt-link-freetext" target="_blank" href="http://cnerg.engr.wisc.edu/">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</blockquote>
<br>
<pre class="yiv4055611019moz-signature">--
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173
</pre>
</div>
</div>
<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a class="moz-txt-link-freetext" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a class="moz-txt-link-freetext" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</body>
</html>