OMEdit fails to simulate

[Adam Dershowitz]

I hope that it is still useful to create tickets that might be Mac related (I can't tell).
I just upgraded from openmodelica-devel @1.17.0~dev-112-g79631af to @1.17.0~dev-126-g0d286e5.

If I try to simulate even a simple example, such as Modelica->Blocks->Examples->PID_Controller, I get the following in my Simulation Output window:

/private/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/OpenModelica_adershowitz/OMEdit/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller -port=65248 -logFormat=xmltcp -override=startTime=0,stopTime=4,stepSize=0.008,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=/private/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/OpenModelica_adershowitz/OMEdit/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller_res.mat -w -lv=LOG_STATS -inputPath=/private/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/OpenModelica_adershowitz/OMEdit/Modelica.Blocks.Examples.PID_Controller -outputPath=/private/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/OpenModelica_adershowitz/OMEdit/Modelica.Blocks.Examples.PID_Controller
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _dgetrf
  Referenced from: /opt/local/lib/x86_64-darwin19.6.0/omc/libsundials_sunlinsollapackdense.3.dylib
  Expected in: flat namespace
 in /opt/local/lib/x86_64-darwin19.6.0/omc/libsundials_sunlinsollapackdense.3.dylib

Process crashed
Process crashed
Simulation process failed. Exited with code 0.

It looks like an issue with compiling and linking to sundials.

[Francesco Casella]

@dersh, as I understand it, the problem we have with Mac is precisely that the management of library dependencies with Mac is becoming impossible. Some are not updated, some are not developed or buggy, it's a nightmare. We have very limited resources and we can't really follow that up.

Our plan is to suggest Mac users to run OMC in Linux virtual machine. Are you available to test this and help us preparing a nice documentation for Mac users how to set that up?

[Adam Dershowitz]

I'm not sure I understand exactly. I just checked and openmodelica does not depend on sundials. In other words there is both a Sundials version 3.1.2 port and a sundials2 2.7.0 port. But, neither seems to be installed on my Mac. Soi, openmodelica is downloading, building using its own version of sundials. It seems like the best way to proceed would be to use an existing port version. Or does OM require a different version? I did also just download and build sundials 5.5 and it was a normal cmake build.
The error looks like it is successfully building a version, since there were no build errors, but then there is a linking problem at simulation build time.

I've run many VMs, including OMC. But, they tend to be slow and inconvenient compared to a native application. Further, Apple is about to release ARM based computers that might not be able to run x86 based VMs. But, code should be able to compile normally and be native.

[Martin Sjölund]

The Sundials versions are not backwards compatible, so we need to use the same version everywhere. For this reason, we build our own version of Sundials; then we also get the same results everywhere.

The error looks like it is successfully building a version, since there were no build errors, but then there is a linking problem at simulation build time.

These are errors in the upstream Sundials version, which does not link lapack as instructed. It's very time-consuming to fix other projects' code to make it work on MacOS.

Further, Apple is about to release ARM based computers that might not be able to run x86 based VMs. But, code should be able to compile normally and be native.

Which is yet another thing we cannot support for that single user who will buy the machine.

[Adam Dershowitz]

I do understand how time consuming it is to fix other projects' code.
Was this new problem due a to a change in the version of Sundials that OM is using? If there's a bug in Sundials then perhaps we can get some assistance from those developers?

I sure will not be that first person getting an ARM Mac. But, eventually they are going to be the norm. So, it would be great to be able to be able to run OM...just wishful thinking. Those machines will be able to run x86 Mac applications through emulation. But, I doubt that running a virtual machine on virtual box will be very efficient, if it works at all.

I am happy to reach out to the Macport folks about getting OM into the repository. But, if it can't even run now, it's going to be a tough sell.

[Martin Sjölund]

But, I doubt that running a virtual machine on virtual box will be very efficient, if it works at all.

As long as you have virtualization support in the hardware, it is fast. And the GUI is even integrated with host's UI when using VirtualBox' seamless mode.

I am happy to reach out to the Macport folks about getting OM into the repository. But, if it can't even run now, it's going to be a tough sell.

Then focus on only releases of OpenModelica. They're not such a moving target.

[Adam Dershowitz]

Replying to sjoelund.se:

But, I doubt that running a virtual machine on virtual box will be very efficient, if it works at all.

As long as you have virtualization support in the hardware, it is fast. And the GUI is even integrated with host's UI when using VirtualBox' seamless mode.

I agree. But, once there is a transition to the ARM based machines that will no longer be the case...

I am happy to reach out to the Macport folks about getting OM into the repository. But, if it can't even run now, it's going to be a tough sell.

Then focus on only releases of OpenModelica. They're not such a moving target.

That makes sense. I've tried to stay on top of the development versions to help debug code as I hoped that would make it easier to keep prevent any big divergence.
But, I think that your suggestion might help get OM to the Macports community, which I think would be good for all.

[Adam Dershowitz]

I just tried to build "openmodelica" (1.16.0~2-g9e481a4) and "openmodelica-release" (@1.16.0) and both fail to build.
I can create a new ticket for each, and can provide the build logs, if that might be helpful.
I realize that with an open project like this, it is extra work, and I do appreciate your help.

[Martin Sjölund]

I agree. But, once there is a transition to the ARM based machines that will no longer be the case...

You don't think Apple will be able to run ARM Linux in a virtual machine? Our code runs on ARM Linux without changes.

I can create a new ticket for each, and can provide the build logs, if that might be helpful.

You'd need to fix the build, too. It built fine for us... We can't test the code after all (can't install the same OSX, XCode, Macports packages), so that means we can't try to fix it.

As long as you have virtualization support in the hardware, it is fast. And the GUI is even integrated with host's UI when using VirtualBox' seamless mode.

And to reaffirm myself, since I tested it. A VirtualBox image running 4 cores is twice as fast as the Macports build running 6 cores+hyperthreading. On the same Mac.

[Adam Dershowitz]

Replying to sjoelund.se:

You don't think Apple will be able to run ARM Linux in a virtual machine? Our code runs on ARM Linux without changes.

If OM runs fun on ARM Linux, that I would expect that would be fine. Again, the ARM issue doesn't concern me for a little while anyway.

I can create a new ticket for each, and can provide the build logs, if that might be helpful.

You'd need to fix the build, too. It built fine for us... We can't test the code after all (can't install the same OSX, XCode, Macports packages), so that means we can't try to fix it.

I'll create the tickets, and perhaps you can offer some suggestions, and I'll see what I can figure out in the build logs.

[Martin Sjölund]

I'll create the tickets, and perhaps you can offer some suggestions, and I'll see what I can figure out in the build logs.

Yes, I can give hints on what might be needed, and what changed in the code

[Francesco Casella]

@dersh, we understand your point, but keeping up with MacOS/MacPorts development is a non-trivial effort for us. OpenModelica is a complex platform with a lot of dependencies, keeping track of them is a huge effort, particularly if they are not kept up-to-date by others. Of course if OMC becomes part of the MacPorts testsuite and the MacPorts community keeps them up-to-date, that would be another story. We struggle to do that ourselves. Could you help with that?

In any case, also based on @sjoelund.se's comment:8, I think we should do some serious testing of virtualized solutions. If the performance is good, this solution will be ideal for us, because it's something we already have, and will work by itself.

In fact, if Windows Subsystem for Linux works well, we may as well skip building OMC for Windows in the future, and only focus on Linux.

[Adam Dershowitz]

I do understand that it is a lot of work, and I do appreciate the work that all of the team has done. Of course it is always easier from a developer perspective to just have one platform. And, it is much easier from a user perspective to have a native application that can just be installed. Many users don't have the knowledge to build an application, even using a tool like Macports that helps. This is all nothing specific to OM, but is a very common problem for all application development.

I am willing to help with macports. But, if I submit a port, and then there are upstream changes to OM, it might break just like sometimes happens . Macports can provide different dependencies. For example macports currently has pugixml 1.10 and OM includes an older version. Apparently, OM is finding the wrong version unless I first disable the pubixml port and fails to build.
So, if I submit the port, that will provide the buildbots, likely more users, and more people who might be able to debug, but it will probably also provide more upstream tickets that could need more assistance.

[Adrian Pop]

Let's continue the discussion on #6306.