Limited File lengths

[ickby]

Hello,

while testing the fem workbench I encountered a rather silly problem:

0.0: Check dependencies...
0.0: C:/Users/****/AppData/Local/Temp/FreeCAD_Doc_fe6f76bc-1050-4d79-908f-f85509edba3b_cce78b_64416/FemAnl_3420/Part__Feature001001_Mesh
0.0: Write mesh...
0.4: Write loads & Co...
0.0: C:/Program Files/FreeCAD 0.15/bin/ccx.exe
0.0: Run Calculix...
0.2: *ERROR in openfile: input file name is too long:
C:/Users/****/AppData/Local/Temp/FreeCAD_Doc_fe6f76bc-1050-4d79-908f-f85509edba3b_cce78b_64416/FemAnl_3420/Part__Feature001001_Mes
exceeds 128 characters

0.2: Calculix done!
0.2: Loading result sets...
0.2: Loading results failed! Results file doesn't exist

Don't know why calculix has a file length restrition, but I suppose this should be considered when the temporary inp file is created, maybe even when creating the tmp directory for the document.

[dubstar-04]

I have also has this problem a few times.

[wmayer]

In the first place this is a stupid limitation of ccx and should be fixed there.

but I suppose this should be considered when the temporary inp file is created, maybe even when creating the tmp directory for the document.

If you choose a shorter file name of document directory this won't really fix the problem because you may have an object with a very long name then you again exceed the limit. IMO, there are two things to check:
* make the current working directory where the .inp is located Then a relative path to ccx can be passed
* if this doesn't work we have to copy the .inp file directly to the temp directory and move the output back to the document sub-directory

[bernd]

In the first place this is a stupid limitation of ccx and should be fixed there.

but I suppose this should be considered when the temporary inp file is created, maybe even when creating the tmp directory for the document.

If you choose a shorter file name of document directory this won't really fix the problem because you may have an object with a very long name then you again exceed the limit. IMO, there are two things to check:
* make the current working directory where the .inp is located Then a relative path to ccx can be passed
* if this doesn't work we have to copy the .inp file directly to the temp directory and move the output back to the document sub-directory

Why not keep ist simple and just do not use the mesh name but some fix name instead like CalculiInputfile.inp for all Calculations. We delete it anyway ...

[dubstar-04]

The temp folder name is the problem for me.

Something like: FreeCAD_Doc_c99f3b2a-4147-4bfc-a95e-7ca27c85bebf_da39a3_4526

The .inp file name is normally short.

[wmayer]

Code: Select all

from PySide import QtCore
p=QtCore.QProcess()

p.start("C:/path/ccx.exe", ['-i',"C:/Very_long_path/FemAnl_eda5/Box_Mesh"])
p.readAll() # indicates error


QtCore.QDir.currentPath()
QtCore.QDir.setCurrent("C:/Very_long_path")

p.start("C:/path/ccx.exe", ['-i',"FemAnl_eda5/Box_Mesh"]) # passing a short relative path
p.readAll() # success

[wmayer]

git commit 1c79de5 should fix it.

[PrzemoF]

In the first place this is a stupid limitation of ccx and should be fixed there.

but I suppose this should be considered when the temporary inp file is created, maybe even when creating the tmp directory for the document.

If you choose a shorter file name of document directory this won't really fix the problem because you may have an object with a very long name then you again exceed the limit. IMO, there are two things to check:
* make the current working directory where the .inp is located Then a relative path to ccx can be passed
* if this doesn't work we have to copy the .inp file directly to the temp directory and move the output back to the document sub-directory

For future reference:
File openfile.f in CalculiX source code (line 34-39):

Code: Select all

      if(i.gt.128) then
         write(*,*) '*ERROR in openfile: input file name is too long:'
         write(*,'(a132)') jobname(1:132)
         write(*,*) '       exceeds 128 characters'
         call exit(201)
      endif

If I ever manage to compile ccx I'll try to increase that and see it that works or it's a fortran limit (I don't think so).

[PrzemoF]

I managed to compile ccx from scratch. It was like a travelling in time back to '70s. That limit is artificial and can be easily (*) fixed.

(*) - easily is relative...

[shoogen]

That limit is artificial and can be easily (*) fixed.

You didn't use a product from the Microsoft recently, did you?
https://msdn.microsoft.com/en-us/librar ... 85%29.aspx