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

[Tim Tautges]

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