[MOAB-dev] cgm2moab as a script

[Tim Tautges]

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).

- tim

On 08/19/2010 04:13 AM, Paul Wilson wrote:
> 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
>

-- 
================================================================
"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