[MOAB-dev] cgm2moab as a script

[Tim Tautges]

One thing I've wondered about whether to do was to consolidate many of the tools we currently write separately (mbsize, 
mbconvert, cgm2moab, etc.), as scripts that all call into a single executable (written in C++, I guess).  This 
consolidated tool would have a single set of options, which would be quite large, but the individual scripts would have 
more limited option sets to be more manageable.  The valgrind suite of tools operates like this, I think.  The 
motivation here would be to only have to implement the common options once, and also to have a fuller set of options 
than you'd get in any of the individual tools, if you wanted to access things that way.

The downside here is that I'm not sure where this falls on ever-changing priority list.

- tim

On 08/17/2010 03: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

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706