Models with long path names cause a code generation failure under Windows

[Francesco Casella]

When compiling model A.B.C.D, the current code generation module generates lots of intermediate files, such as A.B.C.D.c or A.B.C.D_12jac.c, etc., which OMEdit places in a directory named again as the full Modelica pathname. So you get filenames such as

C:\Users\John Doe\AppData\Local\Temp\OpenModelica\OMEdit\A.B.C.D\A.B.C.D_12jac.c

In case of libraries with long class names (which are encouraged in Modelica) and many nested packages, the full pathname can become very long and exceed the Windows limit of 256 characters on path names. This causes some models (e.g. in the ScalableTestSuite or PowerGrids library to fail without any apparent reason during code generation, which is very annoying.

Although it may makes sense to use the full pathname for the temp directory, to avoid aliasing, I understand there is really no need to use the full Modelica pathname as a prefix for all the intermediate filenames, since it is the same for all of them; I guess just using the last identifier (D in this case) would do, and would help mitigating the problem.

Using only D as prefix for the filenames looks like a very quick fix, that we should implent ASAP.

[Francesco Casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

This is very much apparent when trying to simulate
Buildings.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.Validation.CylindricalHeatSource in OMEdit.

[Christoph Buchner <buchner@…>]

As a fix, you can maybe implement using extended-length paths, see the discussion at ​https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation. This mainly means adding a \\?\ prefix to paths.
I don't know if this plays nicely with OM internals, but I have successfully done this in Python code in the past - see an equivalent change that also includes UNC path handling ​here.

Btw, I think the limit is 260 chars, not 256.

[Martin Sjölund]

You can manually set whatever prefix you want. Even in OMEdit (Simulation Setup -> Output -> File Name Prefix (Optional))

[Adrian Pop]

The problem with using UNC paths is that gcc and make in msys2 didn't understand these.
So we could generate the code but not compile it.
I think that after the update to OMDev, the new gcc or maybe clang could work with UNC paths.
I'm not sure about make.

Another problem with UNC paths is that all the path handling needs to be done in the program, i.e. realpath, handling relative paths, etc.

I will do some checks with the new OMDev/msys2 and see if the UNC handling has been improved.

[Christoph Buchner <buchner@…>]

Note: the extended-length path thing and UNC are somewhat orthogonal, but *if* you are using UNC paths, you need to tweak the fix beyond just slapping on a prefix. If you don't just the prefix "should" be fine (I haven't checked, though).

[Francesco Casella]

Replying to sjoelund.se:

You can manually set whatever prefix you want. Even in OMEdit (Simulation Setup -> Output -> File Name Prefix (Optional))

This is not at all clear. By default that combo box is empty. What happens if I put in something? Is more stuff added to the already very long pathname?

[Martin Sjölund]

This is not at all clear. By default that combo box is empty. What happens if I put in something? Is more stuff added to the already very long pathname?

It becomes whatever you put in there.

[Francesco Casella]

Yeah, it could be a nice workaround, but you need to figure out first that the problem is that the default prefix is too long for Windows to handle. Not easy based on the OMEdit output.

I remain strongly in favour of not using the whole path name, but just the model name. It's simple and it solves most problems to most users automatically.

Can't we just do that, for starters?

[Adeel Asghar]

See ​PR#7152.

[Francesco Casella]

Replying to adeas31:

See ​PR#7152.

This fixes the issue in most cases: assuming 20-40 characters for the working directory base path (BTW, one could also use something short as c:\temp\omc), and 10-20 characters for the model name, there are over 200 characters left for the fully qualified name of the model being simulated. I think this is enough even for very complex and structured libraries. The longest fully qualified names in Buildings are around 120 characters.

[Francesco Casella]

I'll check tomorrow with the nightly build and then close the ticket.

[Francesco Casella]

Looks good, except that the .log file still uses the fully qualified name.

@adeas31, can you also take care of that?

Thanks!

[Adeel Asghar]

Nice catch! Thanks for testing this @casella. The .log file name is fixed in 699fb91/OpenModelica.

[Francesco Casella]

Just started a new nightly build. Will cross-check asap.

[Francesco Casella]

Worked like a charm. Going, going, gone!