SteveDoyle2 / pyNastran

A Python-based interface tool for Nastran's file formats
Other
384 stars 147 forks source link

Writing include files fails when includes are located in more than 1 directory #785

Closed lgbav8r closed 3 months ago

lgbav8r commented 3 months ago

bdf\bdf_interface\write_mesh_file.py line 152

Lines 152-157 determine the relative directory name. This is determined once and then line 160 on loops through each include filename but relies on only 1 relative directory.

The relative directory needs to be determined for each include file...not once for all the include files.

SteveDoyle2 commented 3 months ago

Can you provide an example that demonstrates the issue?

lgbav8r commented 3 months ago

I was trying to provide an example but when I made a simple version it worked as I expected...I will have to take another look at my main code. I will reopen if needed.

lgbav8r commented 3 months ago

Reopening this issue as I (re)discovered the issue.

The problem seems to occur when the main bdf which calls include files is located in a different directory than the current directory (where the script is run). My initial test example had the run directory and the main bdf directory as the same.

The actual include files are written to the correct location. However, the INCLUDE card that is written to the bdf file is incorrect. I have used both the default relative_dirname parameter with BDF.write_bdfs() and relative_dirname=''.

I believe my use case should need relative_dirname=None which should use the absolute path. When using that my include files look like the following:

INCLUDE 'pyNastran_test\Dir A\nodeset1_NEW_VERSION.bdf' INCLUDE 'pyNastran_test\Dir B\nodeset2_NEW_VERSION.bdf'

Given the directory structure and where the main bdf file is located. The include statements should be INCLUDE 'Dir A\nodeset1_NEW_VERSION.bdf' INCLUDE 'Dir B\nodeset2_NEW_VERSION.bdf'

The issue can be replicated using the attached zip file and maintaining the directory structure and also running the python script from its own directory.

SteveDoyle2 commented 3 months ago

Looks like the includemap order defines what the relative directory is. Your main bdf should be first. It's confused and thinks your include file is the main file.

includemap= {}
for i in range(len(fem.include_filenames[0])):
    ifilename = fem.include_filenames[0][i]
    includemap[ifilename] = ifilename[:-4] + "_NEW_VERSION" + ifilename[-4:]
includemap[fem.active_filenames[0]] = bdfinput[:-4] + "_NEW_VERSION" + bdfinput[-4:]

should be:

includemap= {}
includemap[fem.active_filenames[0]] = bdfinput[:-4] + "_NEW_VERSION" + bdfinput[-4:]
for i in range(len(fem.include_filenames[0])):
    ifilename = fem.include_filenames[0][i]
    includemap[ifilename] = ifilename[:-4] + "_NEW_VERSION" + ifilename[-4:]

You should also be using:

fem.write_bdfs(includemap, is_windows=True, relative_dirname='')

You can also explicitly set the relative_dirname to a str/Path.

I'm not really sure what the None use case is for. It seems odd the output would change based on your folder location.

lgbav8r commented 3 months ago

Ok. I understand. I will have to try that and see how it works. I didn't catch that the main bdf file should be first in any documentation.

SteveDoyle2 commented 3 months ago

Yeah it’s not the best. I think I’m going to remove the None option as well. It’s very confusing. The new default will be the ‘’ option, so the first bdf in the dictionary.

I think there’s also a bug if you have an include with another include layer. I’d think the way it’s done above should be correct, but I think it does need a path relative to the parent file.

On Mon, Jun 3, 2024 at 3:01 PM lgbav8r @.***> wrote:

Ok. I understand. I will have to try that and see how it works. I didn't catch that the main bdf file should be first in any documentation.

— Reply to this email directly, view it on GitHub https://github.com/SteveDoyle2/pyNastran/issues/785#issuecomment-2146199945, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICUWMFYKU2UBRGXUZZJGDZFTRR3AVCNFSM6AAAAABIN2WXJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBWGE4TSOJUGU . You are receiving this because you commented.Message ID: @.***>

lgbav8r commented 3 months ago

The resolution @SteveDoyle2 provided works. I will close this issue.