OPENMODELICALIBRARY and MODELICAPATH ignored?

[john.pye@…]

Hi there,

With SolarTherm (​https://github.com/SolarTherm/SolarTherm), we execute 'omc' directly to compile our models, and then we invoke the model executable ('C runtime') to run our simulations.

We use CMake to install our model library in a user-selectable file location, and rely on the ability to set OPENMODELICALIBRARY environment variable to point correctly at the location of our bespoke model library. Normally we install our files to ~/.local/lib/omlibrary/SolarTherm, for example.

With OM 1.14 and also (I believe) 1.15, this worked fine, and 'omc' would correctly find our models and simulation could proceed.

However in OM 1.16, we have found that 'omc' doesn't find the model files, and gives us an error about failing to load the package and advising us of the current value of MODELICAPATH:

<env>john@thunder:~/solartherm/examples$ st_simulate --np 0  SimpleSystem.mo 
Compiling model
Error processing file: /home/john/solartherm/examples/SimpleSystem.mo
Failed to load library: SolarTherm!

Notification: Automatically loaded package Complex 3.2.3 due to uses annotation.
Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation.
Notification: You can install the requested package using one of the commands:
  installPackage(SolarTherm, "0.2.0-master", exactMatch=true)
  installPackage(SolarTherm).
Error: Failed to load package SolarTherm (default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/john/.openmodelica/libraries/.

# Error encountered! Exiting...
# Please check the error message and the flags.
Failed to load library: SolarTherm!

Execution failed!
Traceback (most recent call last):
  File "/home/john/.local/bin/st_simulate", line 138, in <module>
    sim.compile_model(args=mcargs)
  File "/home/john/.local/lib/python2.7/site-packages/solartherm/simulation.py", line 276, in compile_model
    + libs)
  File "/usr/lib/python2.7/subprocess.py", line 190, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['omc', '-s', '-q', '-n=0', '-i=SimpleSystem', '/home/john/solartherm/examples/SimpleSystem.mo', 'Modelica', 'SolarTherm']' returned non-zero exit status 1
<env>john@thunder:~/solartherm/examples$ 

I note that we have the OPENMODELICALIBRARY environment variable set as earlier advised:

<env>john@thunder:~/solartherm/examples$ env|grep MODELICA
_OPENMODELICALIBRARY=
OPENMODELICALIBRARY=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary

I note that if I set MODELICAPATH to equal our above value of OPENMODELICALIBRARY:

<env>john@thunder:~/solartherm/examples$ export MODELICAPATH=$OPENMODELICALIBRARY

THEN, it *still* doesn't work; I get the same error:

<env>john@thunder:~/solartherm/examples$ st_simulate --np 0  SimpleSystem.mo 
Compiling model
Error processing file: /home/john/solartherm/examples/SimpleSystem.mo
Failed to load library: SolarTherm!

Notification: Automatically loaded package Complex 3.2.3 due to uses annotation.
Notification: Automatically loaded package ModelicaServices 3.2.3 due to uses annotation.
Notification: You can install the requested package using one of the commands:
  installPackage(SolarTherm, "0.2.0-master", exactMatch=true)
  installPackage(SolarTherm).
Error: Failed to load package SolarTherm (default) using MODELICAPATH /usr/bin/../lib/omlibrary:/home/john/.openmodelica/libraries/.
[...]

And to double check,

<env>john@thunder:~/solartherm/examples$ env|grep MODELICA
MODELICAPATH=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary
_OPENMODELICALIBRARY=
OPENMODELICALIBRARY=/home/john/.openmodelica/libraries:/home/john/.local/lib/omlibrary:/usr/lib/omlibrary:/usr/local/lib/omlibrary

So it seems that whatever support previously existed for using environment variables to control 'omc' has become broken, and it seems that the error message being provided by OMC is inaccurate, since even setting MODELICAPATH doesn't seem to work.

Any thoughts?

Cheers
JP

[Francesco Casella]

@sjoelund.se, could you please help @john.pye with this? Thanks!

[Martin Sjölund]

Seems @adrpo disabled that: ​http://github.com/OpenModelica/OpenModelica/commit/a6054a570af6751198942b4c388cad2f69394e30

I'm not sure why OPENMODELICALIBRARY was disabled; it's still useful. Maybe it was to ignore whatever old env.var was installed in Windows?

MODELICAPATH is just a concept; it was not used in OpenModelica since that might interfere with other Modelica tools.

It would work if you used a mos-script (or OMPython) to set the path, but not calling omc on a .mo-file directly.

[Adrian Pop]

I disabled OPENMODELICALIBRARY because on Windows it would point to older OpenModelica installations.

I guess this is wrong and I should put it back, maybe with a warning that tells the user it doesn't point to where the installation path we get from the dll points.

[Martin Sjölund]

Or perhaps changing the installer to ask to remove the env.var?

[Adrian Pop]

That would break older installs.

[Martin Sjölund]

That's why I said it should ask if it can remove the env.var :)

[John Pye <john.pye@…>]

I've done some wrangling with env vars and this sort of thing in the past, so here are my further thoughts:

Perhaps your old setup process used to depend on setting an environment variable at installation time. That was probably a bad approach, since clearly it messes up if multiple versions are present, and seems to be the basis of your recent decision.

A better approach would be that the env var is an optional feature for power-users and command-line hackers etc. During the installation process, the env var is NOT set, but instead determined from the registry and/or inferred from other file locations. Only if someone wants to add extra paths other than the default ones should they use the env var.

Perhaps the best approach is the one taken by PYTHON, which I feel is very sensible, which is that PYTHONPATH is used (basically only by the power-user) to ADD EXTRA path elements to the system path. It augments rather than replace the standard path. ​https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH

Regarding transition issues, I suggest that for future installations on Windows, you alert the user at install time for cases where an env var is set. You can give the user the choice of (1) leaving the problem there, with the user accepting that it may break their installation, (2) erasing the existing env var, (3) canceling the installation.

[Martin Sjölund]

Replying to John Pye <john.pye@…>:

Perhaps your old setup process used to depend on setting an environment variable at installation time. That was probably a bad approach, since clearly it messes up if multiple versions are present, and seems to be the basis of your recent decision.

Only the Windows version did so. The Linux version is sane :)

[Adrian Pop]

PR: ​https://github.com/OpenModelica/OpenModelica/pull/6687
should fix this. Later on we can fix the Windows installer.

[John Pye <john.pye@…>]

Great! We'll check it out in an upcoming nightly build, I guess?

By the way, why do the documentation and error messages refer to MODELICAPATH when in reality the active variable is OPENMODELICALIBRARY? See original comments above, and the PR that is cited above.

[Martin Sjölund]

It's controlled by setModelicaPath and getModelicaPath. In the Modelica language specification it is called MODELICAPATH. And in OMEdit it is also referred to as MODELICAPATH. It is just that we use a different environment variable for the default value...

[John Pye <john.pye@…>]

This seems very misleading! If I understand correctly, the documentation and error messages instruct the user to set the MODELICAPATH env var, but actually they are supposed to know that when they are asked to do that, they should actually set the OPENMODELICALIBRARY env var...? Where is one supposed to discover this information, if all the documentation and error messages refer to MODELICAPATH?

May I suggest that in the near term, any code that is under the control of the OM project should be modified to correctly refer to the OPENMODELICALIBRARY env var, instead of something misleading to the end user. And certainly any error messages that are provided by OM should refer to the correct env var.

Then perhaps longer-term approach would be to implement support for both OPENMODELICAPATH, MODELICAPATH and OPENMODELICALIBRARY. This would provide compatible behaviour with the Language Specification (based on what you said, not based on my own reading) but still give flexibility for users with multiple Modelica tools on their machine. Perhaps for example:

(1) if OPENMODELICALIBRARY is provided, use that to *set* the search path, then stop. Give a deprecation warning to the user to tell them that they should use OPENMODELICAPATH in future. This restores compatibility with existing OM release-version 1.14 behaviour.

(2) else if OPENMODELICAPATH is provided, use that to *augment* the search path, then stop.

(3) else if MODELICAPATH is provided, use that to *augment* the search path.

This way, one could easily override the MODELICAPATH if desired, but as different Modelica implementations converge, this may bring increasing convenient to users, since they would only need to use a single env var.

[Adrian Pop]

We will discuss about this in our next dev meeting.
From my side I would like to avoid having yet another env var.

[Adrian Pop]

15fefd0/OpenModelica partially fixes this ticket by considering OPENMODELICALIBRARY env var as default for Modelica path.

For the other parts OMEdit/documentation/etc. we will keep it open.

[Francesco Casella]

Replying to adrpo:

15fefd0/OpenModelica partially fixes this ticket by considering OPENMODELICALIBRARY env var as default for Modelica path.

This is now included in the 1.16.0 release.

For the other parts OMEdit/documentation/etc. we will keep it open.

I guess we need to proceed to release 1.16.1 quickly, so I'd postpone this to 1.17.0. If this is really important to have, we can make a 1.16.2 later on.

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed