[MOAB-dev] cgm2moab as a script

Steve Jackson sjackson at cae.wisc.edu
Tue Aug 17 15:19:10 CDT 2010


(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


More information about the moab-dev mailing list