[MOAB-dev] cgm2moab as a script

Paul Wilson wilsonp at engr.wisc.edu
Thu Aug 19 04:13:16 CDT 2010


  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 --------------
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/920c3667/attachment.bin>


More information about the moab-dev mailing list