Long filepaths for ElmerSolver input

[nikosavola]

I tried running ElmerSolver for a sif file with a very long filepath containing hashes and timestamps but it failed due to

ERROR:: MAIN: Unable to find input file [/tmp/swp/session_2023-08-02_13-49-14_791016_1175879/runtime_resources/working_dir_files/tmp/add7326a134a4d29add7c4ed910ea4ae/set], can not execute.
STOP 1

where the file to run would have been called setup.sif at the end. The amount of characters in the error is 128, which makes me assume this is set by MAX_NAME_LEN or MAX_STRING_LEN in

elmerfem/fem/src/Types.F90

Line 57 in b72e8ce

INTEGER, PARAMETER :: MAX_NAME_LEN = 128, MAX_STRING_LEN=2048

Is there a way to circumvent this problem ? (aside from just increasing the value)

[ettaka]

Maybe one could use MAX_STRING_LEN for sif filename? Or then make another parameter for it. One can also allocate if a dynamic approach is needed.

[raback]

I guess this was addressed and can be closed?

[jvencels]

Is this relevant to the error when user uses very long path names?

[16:14:44] STOP 1
[16:14:44] ERROR:: MAIN: Unable to find input file [C:\Users\johnk\TrafoloProjects\2024\August20_verylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpat], can not execute.

C:\Users\johnk\TrafoloProjects\2024\August20_verylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpathverylongpa>**elmersolver case1.sif**
ELMER SOLVER (v 9.0) STARTED AT: 2024/08/20 16:16:27
ParCommInit:  Initialize #PEs:            1
MAIN:
MAIN: =============================================================
MAIN: ElmerSolver finite element software, Welcome!
MAIN: This program is free software licensed under (L)GPL
MAIN: Copyright 1st April 1995 - , CSC - IT Center for Science Ltd.
MAIN: Webpage http://www.csc.fi/elmer, Email elmeradm@csc.fi
MAIN: Version: 9.0 (Rev: Release, Compiled: 2024-08-06)
MAIN:  Running one task without MPI parallelization.
MAIN:  Running with just one thread per task.
MAIN:  Lua interpreter linked in.
MAIN:  External optimization routines linked in.
MAIN: =============================================================
OpenIncludeFile: Trying to include file: mesh/mesh.names
ERROR:: OpenIncludeFile: Cannot open include file: mesh/mesh.names
STOP 1

[tmyllaeri]

I confirm that the 128 character path restriction still holds. Would it be possible to increase this or use MAX_STRING_LEN for paths also?

[juharu]

I confirm that the 128 character path restriction still holds. Would it be possible to increase this or use MAX_STRING_LEN for paths also?

My take is that we can safely increase the number. What might be the appropriate length to cover all usages ?

[tmyllaeri]

I think 512 would be enough for most realistic purposes. Though, in optimal scenario of course any linux paths could be supported, which I guess is usually 4096 characters (value of PATH_MAX). If it doesn't have any adverse effects I guess that could be used to cover all cases

[juharu]

added a separate MAX_PATH_LEN variable (4096), and tried to use it in relevant places. don't know whether I did cover all places, so any testing appreciated ...

[tmyllaeri]

Thanks! I think we are missing the relevant variables in at least in ElmerSolver.F90. ModelName seems to be the variable holding the path to the sif file. Maybe also OutputDirectory, MeshDir, MeshName would need the path limit

Taking a quick look at the code it is maybe not very straightforward task to find all relevant variable declarations where MAX_PATH_LEN should be used. For example one could define output files inside specific solvers with `Filename = "very_long_path/with_many_parts.dat". Changing these consistently in all solvers could be quite tedious..

Not sure what would be the optimal solution here in the end

[juharu]

Thanks. I changed the variables referring to files or directories to larger buffer sizes. I guess, we can change further variables if problems arise. At some point I can also check which of those could reasonably be changed to dynamics strings...

[tmyllaeri]

There are still some inconsistencies with the path lengths: If I try setting Mesh DB in sif longer than 128 characters Elmer segfaults after the print LoadMesh: Elapsed REAL time

Backtrace for this error:
#0  0x7f5fe9ad0e59 in ???
#1  0x7f5fe9acfe75 in ???
#2  0x7f5fe97f732f in ???
#3  0x7f5fea03d4e8 in __modeldescription_MOD_loadmodel
        at /opt/src/elmerfem/fem/src/ModelDescription.F90:3011
#4  0x7f5fea7fca20 in elmersolver_
        at /opt/src/elmerfem/fem/src/ElmerSolver.F90:390
#5  0x562d7b5e93eb in solver
        at /opt/src/elmerfem/fem/src/Solver.F90:57
#6  0x562d7b5e915e in main
        at /opt/src/elmerfem/fem/src/Solver.F90:34

Maybe due to the MAX_NAME_LEN here https://github.com/ElmerCSC/elmerfem/blob/a55711ed30df7bcc38d3a25d62a3989ef667f534/fem/src/ElmerSolver.F90#L390C10-L390C91

Also If the combined length of Results Directory in the header and Output File Name in ResultOutputSolver (or any other solver saving data) is over 128 characters Elmer crashes. This is quite expected since we didnt modify the solvers. The solvers of interest for us are ResultOutputSolver, VtuOutputSolver, SaveScalars, StatElecSolve, StatElecSolveVec, VectorHelmholtz (+ their dependencies). But maybe it would be better to do these changes somehow consistently to the whole repository?

[juharu]

Yes, it seems Mesh_t-strucure sometimes holds the name of the mesh. I'll change that to dynamic.

[juharu]

Yes, it seems Mesh_t-strucure sometimes holds the name of the mesh. I'll change that to dynamic.
done

[tmyllaeri]

Thanks! Tested that Elmer can be now run with long paths to .sif and meshes.

Would it be possible to also increase the size of solver output path buffers? I did some testing in a fork and these changes seem to be sufficient for the solvers we use tmyllaeri@9e92f9a. Not sure if all of them are strictly necessary

[ettaka]

@juharu thanks for the efforts! It looks like there are still some places where the longer paths are required. In my understanding the changes proposed by @tmyllaeri above is enough for his work to continue but is not sufficient to solve the whole issue. Could you help us with this? Thanks!

[tmyllaeri]

I created a pull request with the changes that should be sufficient to us

#649