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

[Dmitry Karpeev]

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).

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.

Dmitry.

On Mon, Apr 5, 2010 at 4:38 PM, Jason Kraftcheck <kraftche at cae.wisc.edu> wrote:
> Dmitry Karpeev wrote:
>> I'm thinking about adding a very simple tool mbparread to the tools subdir.
>
> The tools are primarily tools that MOAB users might find useful.  I'm not
> sure that the tool you propose fits that catagory.
>
>> This is a stripped down version of mbconvert that merely reads a file
>> and reports the times.
>
> Why not just use mbconvert?
>
>> I simply want something a bit more flexible than mbparallelcomm_test
>> (plus, that test seems to fail
>> for mysterious reasons when mbconvert doesn't): it's easier to drive
>> mbconvert using "-O <read_opt>".
>> The reason I want to add it to tools is that I would like it rebuilt
>> automatically when I rebuild the whole tree.
>>
>
> Almost everyone has code that they'd like rebuild automatically.  That isn't
> sufficient justification, IMO, to add it to the MOAB build system as a tool
> we provide to users.
>
>> Let me know if this is okay.
>>
>
> It isn't my decision to make.  However, I generally prefer not to duplicate
> code and/or functionality unnecessarily.  Some things you might want to
> consider are:
>  1) Is this something that is useful to users?
>     1.a) Sufficiently useful that we want to maintain it from now on?
>  2) Is there no existing tool that can be used (e.g. mbconvert)?
>     2.a) Is there an existing tool that could be used with minor
>          modifications?
>
> Also, the tool you are proposing seems to duplicate functionality in
> mbparallelcomm_test that was intended for exactly the same purpose.  Why not
> just fix/modify mbparallelcomm_test?
>
> - jason
>