[MOAB-dev] cgm2moab as a script
Paul Wilson
wilsonp at engr.wisc.edu
Thu Aug 19 04:13:16 CDT 2010
Hi Steve,
One reason to use cgm2moab other than strictly for dagmc pre-processing
is to generate a mesh-based geometry representation for visualization
(e.g. in VisIt). This use case will probably make use of any faceting
controls that are exposed in cgm2moab but does NOT require OBB/implicit
complement processing. (... and ideally, will remove the graveyard, but
that should be taken care of by subset manipulations in VisIt, hopefully).
Paul
On 8/17/2010 10:19 PM, Steve Jackson wrote:
> (Note to all: if you use cgm2moab, please read the last paragraph of this message.)
>
> On Aug 17, 2010, at 14:18 , Jason Kraftcheck wrote:
>
>> Why do you want to make this change at all? Is there any active development
>> on cgm2moab that would be made easier?
> It wouldn't greatly improve the lives of developers in the short term. The chief reason to go to a script would be to simplify the code base. All else being equal, it's better to have dozens of lines of script instead of hundreds of lines of c++. I agree, though, that it's not worth introducing a whole scripting setup for MOAB just for this minor utility.
>
>> Should we just remove the utility? Is it frequently used? It is a lot
>> simpler to use a more specialized utility as opposed to mbconvert, but is
>> there a sufficient number of users to justify maintaining such a utility in
>> MOAB, installing it for all users, etc. as opposed to just letting users
>> write their own wrapper script?
> To my knowledge, its chief (only?) use in practice is to preprocess CAD data for use by dagmc.
>
> Paul and I have discussed extending cgm2moab to optionally do even more preprocessing for dagmc (e.g. build and save the OBB tree structures, a slow process normally done when dagmc is initialized). If we decide to do this, then the question of using a scripting language becomes moot, because the new features would require C++. But if we do this, then 'cgm2moab' becomes something of a misnomer; I'd be tempted to call the program 'dagmc_prep' or similar.
>
> It would be useful to know if anyone is using cgm2moab for purposes *other* than dagmc preprocessing. If not, perhaps it should be renamed and repurposed as a dagmc preprocessing tool.
> ~S
--
Paul Wilson
-- ------------------------------------------------------------------ --
Paul P.H. Wilson 419 Engineering Research Building
wilsonp at engr.wisc.edu 1500 Engineering Dr
ph/fax: 608/263-0807 Madison, WI 53706
My calendar: http://bit.ly/pphw-calendar
Computational Nuclear Engineering Research Group
http://cnerg.engr.wisc.edu
Associate Professor, Nuclear Engineering
Engineering Physics Department
http://www.engr.wisc.edu/ep
Chair, Energy Analysis& Policy Certificate
Nelson Institute for Environmental Studies
http://nelson.wisc.edu/eap/
Contributing to the joy and improvement
of all those around me
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3297 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100819/920c3667/attachment.bin>
More information about the moab-dev
mailing list