[MOAB-dev] Reader/Writer filename extension access

[Jason Kraftcheck]

Jason Kraftcheck wrote:
> Steve Jackson wrote:
> 
>> It would be *cosmetically* better to know the file reader ahead of time
>> because DagMC passes some CGM-specific options to load_file().  If the
>> CGM reader is not the one that's used to load the input, then these
>> options cause load_file() to return the MB_UNHANDLED_OPTION error code.
>> This means load_file() returns an error whenever a mesh file is
>> specified.  I'd rather this error only appeared under strange/unexpected
>> circumstances, instead of all the time.
>>
> 
> This sounds more like an issue with the way we do options.  Knowing which
> reader MOAB will use seems like just as much of a hack.  Perhaps we should
> have some syntax for specifying which file format an option is intended for,
> such that it is not an error if the file is some other format.  Or perhaps
> the whole MB_UNHANDLED_OPTION thing was a bad idea.  I can't recall why we
> decided to add that.
> 

Apologies for replying to my own message.  If we do choose to go the route
of supporting format-specific options, then I think the best way to do that
is to have an option in the string of options that indicates that all
following options (up to the next whatever) apply only to a specific file
format.  Using an "every thing after this" type scheme avoids the need to
introduce some other syntax/separator to the option string itself.

An example:

options="PARALLEL;EXODUS;PARTITION=MATERIAL_SET"

The occurrence of a file format name (EXODUS) in the string would mean that
everything following that format name applies only if that specific format
is read.  In this case, the option string mean that a parallel read is done
using the default partitioning scheme except when the file is an Exodus
file, in which case the mesh should be partitioned by material blocks.

If there is some concern about conflicts between option names and file
format names, then some prefix character (e.g, '>' or '*') could be used.
Or we could use something more explicit such as "LIMIT:EXODUS" or
"RESTRICT=EXODUS".  If we want to allow for more complex things such as
specifying multiple formats for which the following options apply, them a
more complex syntax may be necessary.


Or as a completely different solution, perhaps we should just use an option
to specify the file format that the reader should assume.  For example
"FORMAT=EXODUS".  The reader would then just fail (we really need an
MB_INCORRECT_FILE_FORMAT error code at some point) if the format didn't
match.  Then the application could specify format-specific options by making
multiple load_file calls until one succeeds.  For DagMC, it would just need
two possible calls: one with the type limited to Cub files and if that fails
then one for any other type.

- jason