[MOAB-dev] Adding tool to trunk/tools okay?

[Dmitry Karpeev]

This just allows me to control the options a little better, while not
incurring additional operations
(e.g., writing of files, as mbconvert does).  It definitely could be
moved someplace else (e.g., tests).

Dmitry.

On Tue, Apr 6, 2010 at 12:41 PM, Tim Tautges <tautges at mcs.anl.gov> wrote:
> At maximum this should be a test (not sure, but I think mbparallelcomm_test
> is this way).  Further, I'm not sure how this is very different from
> mbparallelcomm_test, since both are calling load_file.  I guess the options
> might be slightly different...
>
> - tim
>
> Jason Kraftcheck wrote:
>>
>> On 04/05/2010 05:27 PM, Dmitry Karpeev wrote:
>>>
>>> I'm fine with moving mbparread somewhere out of tools/.
>>> The main motivation for introducing another "tool" (more like a test)
>>> was to simplify the code
>>> as much as possible (relative to mbconvert and mbparallelcomm_test) to
>>> try to isolate the
>>> cause of the problems I encounter when benchmarking parallel mesh
>>> reads (more on that in a separate
>>> forthcoming email).
>>
>> I looked at your tool, and it is basically mbconvert with a bunch of the
>> code deleted.  The call to Interface::load_file is identical between your
>> tool and mbconvert assuming you do not specify any of the mbconvert command
>> line options for which you deleted the code in your tool.  So I don't see
>> how this really helps to isolate anything.  You could have just written this
>> as a shell script around mbconvert:
>>
>> #!/bin/sh
>> MOAB_DIR=somewhere
>> ${MOAB_DIR}/tools/mbconvert "$@" -t VTK /dev/null
>>
>>
>>>
>>> Writing a tool like that as a stand-alone app appears complicated at the
>>> moment.
>>> In particular, when I stripped off parts of mbparallelcomm_test to
>>> simplify it a bit,
>>> I found out that the resulting code has to be built within the MOAB
>>> source tree,
>>> since it requires access to the internals, which is controlled by
>>> various #defines, etc.
>>>
>>> I'm definitely open to suggestions on where this piece of code should end
>>> up.
>>> At the moment I needed to write something quickly to chase down some
>>> of the problems I keep running into.
>>
>> The first question to ask is whether or not this belongs in the svn repo
>> at all.  Is it something that will be used by others in the future?  Is it a
>> new and/or unique capability?  How you build your test code (by adding it to
>> MOABs build system or as a standalone app is your concern.)  But checking it
>> into the repo as either a tool or a test implies that others will be
>> responsible for maintaining this code in the future (updating it for API
>> changes, portability fixes, etc.)
>>
>> The second question is, if it is in the repository, should it be build as
>> a test (i.e. compiled during 'make check' and never installed) or as a tool
>> (compiled during 'make' and installed in ${prefix}/bin.)  A tool is
>> something that users will want to use.  Further, as a tool, we are to some
>> degree expected to provide documentation and user support.
>>
>> - jason
>>
>
> --
> ================================================================
> "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
>
>