[MOAB-dev] cgm2moab as a script

[Paul Wilson]

  Hi Tim,

But this raises questions about what "should" be in a reader and what 
shouldn't.  Do we want the CGM reader to include options that are 
specific to DAGMC users?  It seems that the following aren't strictly 
functions of a reader:

    * OBB tree generation
    * Implicit complement generation
    * Graveyard removal/suppression

Paul

On 8/19/2010 4:03 PM, Tim Tautges wrote:
> 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
>>
>

-- 
Paul Wilson

-- ------------------------------------------------------------------ --
Paul P.H. Wilson              419 Engineering Research Building
wilsonp at engr.wisc.edu                       1500 Engineering Dr
ph/fax: 608/263-0807                          Madison, WI 53706

            My calendar: http://bit.ly/pphw-calendar

        Computational Nuclear Engineering Research Group
                http://cnerg.engr.wisc.edu

           Associate Professor, Nuclear Engineering
               Engineering Physics Department
                http://www.engr.wisc.edu/ep

         Chair, Energy Analysis&  Policy Certificate
          Nelson Institute for Environmental Studies
                 http://nelson.wisc.edu/eap/

           Contributing to the joy and improvement
                   of all those around me

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100819/de5923d1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3297 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100819/de5923d1/attachment.bin>