On Wed, Aug 19, 2009 at 9:36 PM, Roy Stogner<roystgnr@...> wrote:
> On Wed, 19 Aug 2009, Andrea Hawkins wrote:
>> In trying to read in a .ele file for the mesh, which should be read in with
>> the Tetgen reader, I was getting errors regarding the Exodus reader. In
>> looking through the function void UnstructuredMesh::read, the else if
>> checking for Exodus files is before the TetGen check and since the one for
>> Exodus checks for ".e", which will be satisfied for ".ele", it is being
>> chosen. I believe switching the order of these will fix the problem.
> That should fix the ".ele" problem, but there's an underlying problem
> here - we're not testing filetype by suffix, we're testing it by
> "infix", which could result in other misidentifications.
> Trying to read a file called "boundary.nodes.gmv", for example, would
> see a ".node" in the filename before checking for ".gmv", and would
> then try to read it with TetGenIO.
> On the other hand, if we switch to only accept suffixes as suffixes,
> then trying to read "whatever.gmv.0001" will fail to identify it.
> Anyone have any other suggestions?
Well, string::rfind returns the position of the last occurrence in the
string of the searched content, otherwise it returns string::npos,
which is like (unsigned)(-1). Thus we could check for a return value
== (string.size() - "n. chars searched") to see if what was found was
truly a trailing file extension.
std::string filename = "datafile.ele";
filename should not trigger the test (filename.rfind(".e") ==
(I didn't test this, so there is likely an off-by-one error, but I
think it's on the right track.)
This will also work for boundary.nodes.gmv, since the ".node" is not
at the end of the name.
For things like datafile.gmv.0001 to register as a .gmv file I think
we can keep doing what we're doing, just keep the "infix" tests at
test at the end of the if-block so that a crazy filename like
this.is.not.a.gmv.file.node would not trigger on gmv before .node.
If we want to handle ridiculous filenames like
gracefully, I see no other option than to find *all* possible matching
file types. In case there is more than one possible match, we could
add a new method to the MeshInput class called something like
try_read() which tries to read enough of the file to ensure that it is
of the correct format, and returns true on success. This is a lot
more work though, I think we can get a lot of mileage out of checking
the actual return value of rfind...