If MOAB is built with dagmc enabled and CGM support, one of the programs installed in bin/ is cgm2moab, a tool for converting CAD files to MOAB meshes. Over time, almost all the the functionality of this program has migrated into MOAB's native CGM reader, so it's now possible to do essentially everything that cgm2moab does using an appropriate call to mbconvert. (Not a terse or convenient call, though, because cgm2moab specifies a lot of lengthy arguments to ReadCGM.) This has led the dagmc users to consider changing cgm2moab into a wrapper script that calls mbconvert, instead of a C++ program. I'm wondering what our primary maintainers think about this idea. Can Tim and/or Jason comment on the following possibilities? * Convert cgm2moab to a python script. (Readability win, requires python, and possibly requires autoconf things to portably detect python.) * Convert cgm2moab to a plain bash script. (Messier code, but probably more portable.) * No thanks, leave it as C++. Thanks. ~S
On 08/17/2010 12:20 PM, Steve Jackson wrote:
If MOAB is built with dagmc enabled and CGM support, one of the programs installed in bin/ is cgm2moab, a tool for converting CAD files to MOAB meshes. Over time, almost all the the functionality of this program has migrated into MOAB's native CGM reader, so it's now possible to do essentially everything that cgm2moab does using an appropriate call to mbconvert. (Not a terse or convenient call, though, because cgm2moab specifies a lot of lengthy arguments to ReadCGM.) This has led the dagmc users to consider changing cgm2moab into a wrapper script that calls mbconvert, instead of a C++ program.
I'm wondering what our primary maintainers think about this idea. Can Tim and/or Jason comment on the following possibilities?
* Convert cgm2moab to a python script. (Readability win, requires python, and possibly requires autoconf things to portably detect python.)
I don't think we should add a dependency on python to MOAB for something this minor. I'm also a little unsure about it being a readability win. While python does a little more to force readability, you don't have to write unmaintainable code in other languages (except perhaps for autoconf/m4, which will have to use to add the configure logic.)
* Convert cgm2moab to a plain bash script. (Messier code, but probably more portable.)
I'm not sure it'd really be more portable. Windows users are more likely to have a python interpreter than a bourne shell.
* No thanks, leave it as C++.
This is probably the most portable option. Why do you want to make this change at all? Is there any active development on cgm2moab that would be made easier? 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? - jason
(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
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 ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
On 08/17/2010 04:02 PM, Tim Tautges wrote:
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.
This would be somewhat of a mess to maintain, and you'd probably run out of single-letter options unless you a) had some options change the meaning of others or b) changed the meaning of the options based on the executable name (e.g. if the app is launched through a symlink named mbconvert, the behavior is different.)
The valgrind suite of tools operates like this, I think.
The valgrind tools work as series of plugins (.so files) for a common emulation engine (the main executable.)
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.
Some common code in a convenience library would accomplish this without the need for one huge application. - jason
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 [email protected] 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
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 ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
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 [email protected] 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
On 08/19/2010 12:31 PM, Paul Wilson wrote:
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
Correct; I'd been going on your statement about using it for things other than strictly dagmc pre-processing. - tim
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 [email protected] 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
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706
participants (4)
-
Jason Kraftcheck -
Paul Wilson -
Steve Jackson -
Tim Tautges