[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