<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Patrick,<br>
<br>
I think there is a global ID tag (or something similar) that should
probably NOT be overwritten. I am not sure of others...<br>
<br>
Paul<br>
<br>
<div class="moz-cite-prefix">On 07/16/2014 09:15 AM, Patrick
Shriwise wrote:<br>
</div>
<blockquote cite="mid:53C688F0.5020408@wisc.edu" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Are there any default tags that are automatically generated upon
creating a new entity in cgm? If so, should those be overwritten
by the tags from the original entity we are copying?<br>
<br>
Patrick<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/16/2014 02:35 AM, Rajeev Jain
wrote:<br>
</div>
<blockquote
cite="mid:1405496102.75774.YahooMailNeo@web122006.mail.ne1.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff;
font-family:lucida console, sans-serif;font-size:10pt">
<div><span>I think all of the tags should get copied, but
there might be use cases (in-future, I can't think of a
case now</span><span style="background-color:
transparent;">) where making things more general and
allowing a user option for selective or complete copying
of tags might prove useful.</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><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;">Rajeev</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> Paul
Wilson <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:wilsonp@engr.wisc.edu"><wilsonp@engr.wisc.edu></a><br>
<b><span style="font-weight: bold;">To:</span></b>
"Jain, Rajeev" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:jain@mcs.anl.gov"><jain@mcs.anl.gov></a>;
shriwise <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:shriwise@wisc.edu"><shriwise@wisc.edu></a>;
CGMA Development <a moz-do-not-send="true"
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>
Wednesday, July 16, 2014 12:09 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="yiv9048384240">
<div> Hi Rajeev,<br clear="none">
<br clear="none">
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
clear="none">
<br clear="none">
Paul<br clear="none">
<br clear="none">
<div class="qtdSeparateBR"><br>
<br>
</div>
<div class="yiv9048384240yqt4985277294"
id="yiv9048384240yqt57613">
<div class="yiv9048384240moz-cite-prefix">On
07/15/2014 08:26 PM, Rajeev Jain wrote:<br
clear="none">
</div>
<blockquote type="cite">
<div style="color: rgb(0, 0, 0); font-family:
'lucida console', sans-serif; font-size: 10pt;
background-color: rgb(255, 255, 255);">
<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
clear="none">
</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 clear="none">
</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 moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv9048384240moz-txt-link-rfc2396E"
ymailto="mailto:shriwise@wisc.edu"
target="_blank"
href="mailto:shriwise@wisc.edu"><shriwise@wisc.edu></a><br
clear="none">
<b><span style="font-weight:bold;">To:</span></b>
Paul Wilson <a moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv9048384240moz-txt-link-rfc2396E"
ymailto="mailto:wilsonp@engr.wisc.edu" target="_blank"
href="mailto:wilsonp@engr.wisc.edu"><wilsonp@engr.wisc.edu></a>;
"Jain, Rajeev" <a
moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv9048384240moz-txt-link-rfc2396E"
ymailto="mailto:jain@mcs.anl.gov"
target="_blank"
href="mailto:jain@mcs.anl.gov"><jain@mcs.anl.gov></a>;
CGMA Development <a
moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv9048384240moz-txt-link-rfc2396E"
ymailto="mailto:cgma-dev@mcs.anl.gov" target="_blank"
href="mailto:cgma-dev@mcs.anl.gov"><cgma-dev@mcs.anl.gov></a>
<br clear="none">
<b><span style="font-weight:bold;">Sent:</span></b>
Tuesday, July 15, 2014 10:29 AM<br
clear="none">
<b><span style="font-weight:bold;">Subject:</span></b>
Re: [cgma-dev] Inconsistency in
getEntities for iGeom interface.
Causes problems in iRel.<br
clear="none">
</font> </div>
<div class="yiv9048384240y_msg_container"><br
clear="none">
<div id="yiv9048384240">
<div> Bump. <br clear="none">
<br clear="none">
<div
class="yiv9048384240moz-cite-prefix">On
07/11/2014 08:15 PM, Paul Wilson
wrote:<br clear="none">
</div>
<blockquote type="cite">Rajeev,<br
clear="none">
<br clear="none">
You are mentioned in the git logs
as the inspiration for the
copy_attrib test that Patrick
mentioned. (a few years ago)<br
clear="none">
<br clear="none">
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
clear="none">
<br clear="none">
Paul<br clear="none">
<br clear="none">
<div
class="yiv9048384240moz-cite-prefix">On
07/11/2014 07:21 PM, Patrick
Shriwise wrote:<br clear="none">
</div>
<blockquote type="cite">Hi all, <br
clear="none">
<br clear="none">
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
clear="none">
<br clear="none">
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
clear="none">
<br clear="none">
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 clear="none">
<br clear="none">
Cheers, <br clear="none">
<br clear="none">
Patrick <br clear="none">
<br clear="none">
<br clear="none">
<div
class="yiv9048384240moz-cite-prefix">On
06/23/2014 03:06 PM, Paul
Wilson wrote:<br clear="none">
</div>
<blockquote type="cite">Hi
everyone,<br clear="none">
<br clear="none">
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
clear="none">
<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
clear="none">
</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
clear="none">
</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
clear="none">
</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
clear="none">
</div>
<div>Paul<br clear="none">
</div>
<br clear="none">
<div
class="yiv9048384240moz-cite-prefix">On
06/17/2014 09:00 AM, Jane Hu
wrote:<br clear="none">
</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 clear="none">
</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 clear="none">
</div>
<div>Jane</div>
</div>
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<br clear="none">
<div
class="yiv9048384240gmail_quote">On
Mon, Jun 16, 2014 at
11:35 AM, Jane Hu <span
dir="ltr"> <<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
ymailto="mailto:janejhu@gmail.com"
target="_blank"
href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>></span>
wrote:<br clear="none">
<blockquote
class="yiv9048384240gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex;">
<div dir="ltr">See
comments below...<br
clear="none">
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<br clear="none">
<div
class="yiv9048384240gmail_quote">
<div
class="yiv9048384240">On
Mon, Jun 16,
2014 at 10:22
AM, Paul
Wilson <span
dir="ltr"><<a
moz-do-not-send="true" rel="nofollow" shape="rect"
ymailto="mailto:wilsonp@engr.wisc.edu"
target="_blank" href="mailto:wilsonp@engr.wisc.edu">wilsonp@engr.wisc.edu</a>></span>
wrote:<br
clear="none">
<blockquote
class="yiv9048384240gmail_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
clear="none">
<br
clear="none">
I think this
needs a
thorough
review!
Patrick and I
hunted through
iGeom_CGMA and
found some
inconsistencies
in a few
places.<br
clear="none">
<br
clear="none">
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
clear="none">
</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="yiv9048384240">
<div> </div>
<blockquote
class="yiv9048384240gmail_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
clear="none">
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
clear="none">
</div>
</blockquote>
<div><br
clear="none">
</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="yiv9048384240h5">
<div> </div>
<blockquote
class="yiv9048384240gmail_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
clear="none">
This means
that 2 calls
into the
interface that
should resolve
to the same
entity may not
do so for both
reasons.<br
clear="none">
<br
clear="none">
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 clear="none">
<br
clear="none">
Paul</font></span>
<div>
<div><br
clear="none">
<br
clear="none">
<div>On
06/16/2014
10:14 AM, Jane
Hu wrote:<br
clear="none">
</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
clear="none">
</div>
<div>Jane</div>
</div>
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<br
clear="none">
<div
class="yiv9048384240gmail_quote">On
Mon, Jun 16,
2014 at 9:32
AM, Jane Hu <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
ymailto="mailto:janejhu@gmail.com"
target="_blank" href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>></span>
wrote:<br
clear="none">
<blockquote
class="yiv9048384240gmail_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"> </font></span>
<div><br
clear="none">
</div>
<div>Jane</div>
</div>
<div>
<div>
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<br
clear="none">
<div
class="yiv9048384240gmail_quote">On
Sun, Jun 15,
2014 at 11:55
PM, Patrick
Shriwise <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
ymailto="mailto:shriwise@wisc.edu"
target="_blank" href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>></span>
wrote:<br
clear="none">
<blockquote
class="yiv9048384240gmail_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
clear="none">
</div>
<div>Will the
ref_volumes()
method return
RefEntities? </div>
<span><font
color="#888888">
</font></span>
<div><br
clear="none">
</div>
<div>Patrick</div>
<div>
<div>
<div><br
clear="none">
On Jun 15,
2014, at 3:56
PM, Jane Hu
<<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
ymailto="mailto:janejhu@gmail.com"
target="_blank" href="mailto:janejhu@gmail.com">janejhu@gmail.com</a>>
wrote:<br
clear="none">
<br
clear="none">
</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
clear="none">
</div>
<div>Good
luck!</div>
<div><br
clear="none">
</div>
<div>Jane</div>
</div>
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<br
clear="none">
<div
class="yiv9048384240gmail_quote">On
Sat, Jun 14,
2014 at 8:55
AM, Patrick
Shriwise <span
dir="ltr">
<<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
ymailto="mailto:shriwise@wisc.edu"
target="_blank" href="mailto:shriwise@wisc.edu">shriwise@wisc.edu</a>></span>
wrote:<br
clear="none">
<blockquote
class="yiv9048384240gmail_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
clear="none">
<br
clear="none">
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
clear="none">
<br
clear="none">
Cheers, <br
clear="none">
<br
clear="none">
Patrick <br
clear="none">
<div>
<div>
<div>On
06/13/2014
11:26 PM, Jane
Hu wrote:<br
clear="none">
</div>
<blockquote
type="cite">
<div dir="ltr"><br
clear="none">
<div
class="yiv9048384240gmail_extra"><br
clear="none">
<div
class="yiv9048384240gmail_quote">
<blockquote
class="yiv9048384240gmail_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
clear="none">
<br
clear="none">
Is there a
way to get
volumes within
bodies via
iGeom?</div>
</blockquote>
<div><br
clear="none">
</div>
<div>See
example in
iGeom_CGMA.cc,
body->ref_volumes(volumes).</div>
<div><br
clear="none">
</div>
<div>Jane</div>
<blockquote
class="yiv9048384240gmail_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 clear="none">
</font></span>
<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" shape="rect" href="">(608) 446-8173</a>
</pre>
</div>
</blockquote>
</div>
<br
clear="none">
<br
clear="all">
<div><br
clear="none">
</div>
-- <br
clear="none">
Jane Hu<br
clear="none">
<br
clear="none">
Asst.
Researcher<br
clear="none">
Dept. of
Engineering
Physics<br
clear="none">
UW @ Madison<br
clear="none">
<br
clear="none">
"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
clear="none">
</div>
</div>
</div>
</blockquote>
</div>
<br
clear="none">
<br
clear="all">
<div><br
clear="none">
</div>
-- <br
clear="none">
Jane Hu<br
clear="none">
<br
clear="none">
Asst.
Researcher<br
clear="none">
Dept. of
Engineering
Physics<br
clear="none">
UW @ Madison<br
clear="none">
<br
clear="none">
"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
clear="none">
<br
clear="all">
<div><br
clear="none">
</div>
-- <br
clear="none">
Jane Hu<br
clear="none">
<br
clear="none">
Asst.
Researcher<br
clear="none">
Dept. of
Engineering
Physics<br
clear="none">
UW @ Madison<br
clear="none">
<br
clear="none">
"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
clear="none">
<br
clear="all">
<div><br
clear="none">
</div>
-- <br
clear="none">
Jane Hu<br
clear="none">
<br
clear="none">
Asst.
Researcher<br
clear="none">
Dept. of
Engineering
Physics<br
clear="none">
UW @ Madison<br
clear="none">
<br
clear="none">
"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
clear="none">
</div>
</div>
<div>
<pre>--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ <a moz-do-not-send="true" rel="nofollow" shape="rect" href="">608-263-0807</a> ~ cal: <a moz-do-not-send="true" rel="nofollow" shape="rect" 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" shape="rect" 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="yiv9048384240h5"><br
clear="none">
<br
clear="all">
<div><br
clear="none">
</div>
-- <br
clear="none">
Jane Hu<br
clear="none">
<br
clear="none">
Asst.
Researcher<br
clear="none">
Dept. of
Engineering
Physics<br
clear="none">
UW @ Madison<br
clear="none">
<br
clear="none">
"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 clear="none">
<br clear="all">
<div><br clear="none">
</div>
-- <br clear="none">
Jane Hu<br clear="none">
<br clear="none">
Asst. Researcher<br
clear="none">
Dept. of Engineering
Physics<br clear="none">
UW @ Madison<br
clear="none">
<br clear="none">
"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 clear="none">
<pre class="yiv9048384240moz-signature">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" rel="nofollow" shape="rect" class="yiv9048384240moz-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" shape="rect" class="yiv9048384240moz-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 clear="none">
<pre class="yiv9048384240moz-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 clear="none">
<pre class="yiv9048384240moz-signature">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" rel="nofollow" shape="rect" class="yiv9048384240moz-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" shape="rect" class="yiv9048384240moz-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 clear="none">
<pre class="yiv9048384240moz-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 clear="none">
<br clear="none">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="none">
<pre class="yiv9048384240moz-signature">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a moz-do-not-send="true" rel="nofollow" shape="rect" class="yiv9048384240moz-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" shape="rect" class="yiv9048384240moz-txt-link-freetext" target="_blank" href="http://cnerg.engr.wisc.edu/">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</div>
</div>
<br>
<br>
</div>
</div>
</div>
</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">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
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>