[MOAB-dev] cgm2moab as a script

Tim Tautges tautges at mcs.anl.gov
Thu Aug 19 09:03:44 CDT 2010


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



More information about the moab-dev mailing list