<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Tim,<br>
<br>
But this raises questions about what "should" be in a reader and
what shouldn't. Do we want the CGM reader to include options that
are specific to DAGMC users? It seems that the following aren't
strictly functions of a reader:<br>
<ul>
<li>OBB tree generation</li>
<li>Implicit complement generation</li>
<li>Graveyard removal/suppression</li>
</ul>
Paul<br>
<br>
On 8/19/2010 4:03 PM, Tim Tautges wrote:
<blockquote cite="mid:4C6D39C0.5080403@mcs.anl.gov" type="cite">But
these should all be enabled by options to things like mbconvert,
maybe not now, but eventually (since the faceting options to
cgm2moab get passed to the cgm reader ultimately).
<br>
<br>
- tim
<br>
<br>
On 08/19/2010 04:13 AM, Paul Wilson wrote:
<br>
<blockquote type="cite">Hi Steve,
<br>
<br>
One reason to use cgm2moab other than strictly for dagmc
pre-processing
<br>
is to generate a mesh-based geometry representation for
visualization
<br>
(e.g. in VisIt). This use case will probably make use of any
faceting
<br>
controls that are exposed in cgm2moab but does NOT require
OBB/implicit
<br>
complement processing. (... and ideally, will remove the
graveyard, but
<br>
that should be taken care of by subset manipulations in VisIt,
hopefully).
<br>
<br>
Paul
<br>
<br>
On 8/17/2010 10:19 PM, Steve Jackson wrote:
<br>
<blockquote type="cite">(Note to all: if you use cgm2moab,
please read the last paragraph of
<br>
this message.)
<br>
<br>
On Aug 17, 2010, at 14:18 , Jason Kraftcheck wrote:
<br>
<br>
<blockquote type="cite">Why do you want to make this change at
all? Is there any active
<br>
development
<br>
on cgm2moab that would be made easier?
<br>
</blockquote>
It wouldn't greatly improve the lives of developers in the
short term.
<br>
The chief reason to go to a script would be to simplify the
code base.
<br>
All else being equal, it's better to have dozens of lines of
script
<br>
instead of hundreds of lines of c++. I agree, though, that
it's not
<br>
worth introducing a whole scripting setup for MOAB just for
this minor
<br>
utility.
<br>
<br>
<blockquote type="cite">Should we just remove the utility? Is
it frequently used? It is a lot
<br>
simpler to use a more specialized utility as opposed to
mbconvert,
<br>
but is
<br>
there a sufficient number of users to justify maintaining
such a
<br>
utility in
<br>
MOAB, installing it for all users, etc. as opposed to just
letting users
<br>
write their own wrapper script?
<br>
</blockquote>
To my knowledge, its chief (only?) use in practice is to
preprocess
<br>
CAD data for use by dagmc.
<br>
<br>
Paul and I have discussed extending cgm2moab to optionally do
even
<br>
more preprocessing for dagmc (e.g. build and save the OBB tree
<br>
structures, a slow process normally done when dagmc is
initialized).
<br>
If we decide to do this, then the question of using a
scripting
<br>
language becomes moot, because the new features would require
C++. But
<br>
if we do this, then 'cgm2moab' becomes something of a
misnomer; I'd be
<br>
tempted to call the program 'dagmc_prep' or similar.
<br>
<br>
It would be useful to know if anyone is using cgm2moab for
purposes
<br>
*other* than dagmc preprocessing. If not, perhaps it should be
renamed
<br>
and repurposed as a dagmc preprocessing tool.
<br>
~S
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Paul Wilson
-- ------------------------------------------------------------------ --
Paul P.H. Wilson 419 Engineering Research Building
<a class="moz-txt-link-abbreviated" href="mailto:wilsonp@engr.wisc.edu">wilsonp@engr.wisc.edu</a> 1500 Engineering Dr
ph/fax: 608/263-0807 Madison, WI 53706
My calendar: <a class="moz-txt-link-freetext" href="http://bit.ly/pphw-calendar">http://bit.ly/pphw-calendar</a>
Computational Nuclear Engineering Research Group
<a class="moz-txt-link-freetext" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a>
Associate Professor, Nuclear Engineering
Engineering Physics Department
<a class="moz-txt-link-freetext" href="http://www.engr.wisc.edu/ep">http://www.engr.wisc.edu/ep</a>
Chair, Energy Analysis & Policy Certificate
Nelson Institute for Environmental Studies
<a class="moz-txt-link-freetext" href="http://nelson.wisc.edu/eap/">http://nelson.wisc.edu/eap/</a>
Contributing to the joy and improvement
of all those around me</pre>
</body>
</html>