[MOAB-dev] iMesh vs. MOAB format for string options
Tim Tautges
tautges at mcs.anl.gov
Tue Oct 27 11:51:58 CDT 2009
As I discussed earlier with Jason, I'm on the fence about this. Always putting a delimiter at the front of the string
looks goofy for single-option strings. Handling options differently between MOAB and iMesh is error-prone. The
question boils down to: be consistent with (what we view as) a flawed standard, or be inconsistent and risk (somewhat
infrequent) errors that result from that inconsistency.
And, phrasing the question in this way, I guess I feel that it's better to be consistent, even though the resulting code
looks goofy. Opinions? Note, this would require changes to existing applications.
- tim
Jason Kraftcheck wrote:
> Both MOAB and iMesh have functions that are passed an optional string
> containing options (e.g. iMesh_loadMesh, iMesh_newMesh, and
> MBInterface::load_file). The format used by the two interfaces is slightly
> different. The MOAB format uses a ';' to separate multiple options, with a
> mechanism to request an alternate separator if necessary. For example:
> BINARY
> or
> PARALLEL=BCAST;MPI_ROOT=1
> or
> ;+PARALLEL=BCAST+MPI_ROOT=1
> The iMesh format requires that the desired separator always be the first
> character in the options string. For example:
> ;BINARY
> or
> ;PARALLEL=BCAST;MPI_ROOT=1
> or
> +PARALLEL=BCAST+MPI_ROOT=1
>
> In the MOAB implementation of the iMesh API, the functions that accept
> option strings convert the string from iMesh to MOAB format before passing
> it to an MBInterface function.
>
> Does anyone feel strongly that we should change the MOAB format to be
> consistent with the iMesh one?
>
> - 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
More information about the moab-dev
mailing list