pyNastran BDF reader does not parse valid INCLUDE having a relative path.

[jeffrey-guy-lyon]

pyNastran version = trunk on 12/17/15 platform: tested on linux 64

I will email you the file 'relative_path_error.zip' that has the example that reproduces this exception.

The deck /foo/test.dat references the file /bar/deck2.bdf. This is done using a relative path INCLUDE '../bar/deck2.bdf', which is a valid NASTRAN INCLUDE statement. The /foo/test.f06 file shows that NASTRAN (NX 8.5) reads in the contents of deck2.bdf, which in this case is a single GRID card.

Running a python script (test.py) to read in the test.dat deck throws an IOError. The traceback is shown below.

~/test/foo $ python test.py DEBUG: fname=bdf.pyc lineNo=742 ---starting BDF.read_bdf of test.dat--- DEBUG: fname=bdf.pyc lineNo=2610 opening '/home/jeffrey.lyon/test/foo/test.dat' No such bdf_filename: u'/home/jeffrey.lyon/test/foo/\home\jeffrey.lyon\test\foo..\bar\deck2.bdf' cwd: '/home/jeffrey.lyon/test/foo' include_dir: '/home/jeffrey.lyon/test/foo' failed: /home/jeffrey.lyon/test/foo/\home\jeffrey.lyon\test\foo..\bar\deck2.bdf passed: /home/jeffrey.lyon/test/foo passed: /home/jeffrey.lyon/test passed: /home/jeffrey.lyon passed: /home passed: / Traceback (most recent call last): File "test.py", line 5, in mesh.read_bdf('test.dat') File "/home/jeffrey.lyon/anaconda/lib/python2.7/site-packages/pyNastran-0.8.0.post0-py2.7.egg/pyNastran/bdf/bdf.py", line 744, in read_bdf bulk_data_lines = self._get_lines(self.bdf_filename, self.punch) File "/home/jeffrey.lyon/anaconda/lib/python2.7/site-packages/pyNastran-0.8.0.post0-py2.7.egg/pyNastran/bdf/bdf.py", line 2431, in _get_lines raise IOError(msg) IOError: There was an invalid filename found while parsing. Check the end of u'pyNastran_crash.bdf' bdf_filename2 = u'\home\jeffrey.lyon\test\foo..\bar\deck2.bdf'

[SteveDoyle2]

Does this work on Windows for you? I'm unable to reproduce the bug.

[jeffrey-guy-lyon]

Unfortunately, my Windows python installation is currently broken (and IT has to get involved) so I can’t test it right now on that platform.

BTW, I put the file to include in the same folder as the main deck and I get the same error, so it’s not the ‘../‘ that’s the problem.

I’ll keep drilling down...

On Dec 17, 2015, at 1:53 PM, SteveDoyle2 notifications@github.com wrote:

Does this work on Windows for you? I'm unable to reproduce the bug.

— Reply to this email directly or view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/255#issuecomment-165579278.

[SteveDoyle2]

If I run MSC Nastran one level below foo "nastran foo/test.dat", I get:

 *** USER FATAL MESSAGE 398 (GETLIN)
     A REQUESTED INCLUDE FILE WAS NOT FOUND.
     FILE '../bar/deck2.bdf'
     IS INCLUDED IN FILE 'foo/test.dat'
     AT RECORD NUMBER 13.
     THE INCLUDE REQUEST IS SKIPPED.

If I run nastran in foo "nastran test.dat", I get:

 *** USER WARNING MESSAGE 4500 (GPSP)
     STIFFNESS MATRIX PURGED, GRID POINT SINGULARITY NOT TESTED.

which is similar to the expected NX message of:

^^^ USER   FATAL   MESSAGE 9058 (SESTATIC)  
^^^ THE SOLUTION FOR THE RESIDUAL STRUCTURE AND THE CURRENT SUBCASE DOES NOT EXIST. 

My understanding of Nastran's screwy filepath requirements is that INCLUDEs are relative to the original folder that you call Nastran from, not relative to the base file (test.dat) or an INCLUDE file.

[jeffrey-guy-lyon]

I was able to reproduce the NASTRAN results. I agree that the INCLUDE statement paths are with respect to NASTRAN's current working directory. In the case of the problem at hand, however, the current working directory is the folder with the test.dat deck, so the INCLUDE paths should work.

The weird thing is that this code used to work in pyNastran. The latest I ran the code before today was 5/5/15. I will roll the version back to see when it breaks.

[SteveDoyle2]

Try and update. I think I fixed the bug. There was a replace / with \, but that should only happen on Windows.

I'm not sure why the 5/5/15 version worked. I really didn't change the include parser.

[jeffrey-guy-lyon]

Oops, most likely of 5/5 I was running it on Windows at the time.

Your patch fixed the problem!

[SteveDoyle2]

Nice!