Features of FMUGeneration

The package FMUGeneration works for me now (see here). Follow-up questions:

  • Is an FMU file always OS specific? Do I need three of them if I want to support Windows, Mac, and Linux?
  • Does the user of an FMU need to have Julia installed?
  • Does the creation of FMUs work on Mac and Windows?
  • Can I create FMUs for Windows on Linux?
  • I have a free, academic license of Dyad. Am I allowed to distribute FMUs to my students? If yes, under which license?

To answer my first question: I think in the context of Julia the answer is (currently) yes, because an OS independent FMU must contain only C source code and no (compiled) shared libraries. In theory, an FMU could also contain shared libraries for multiple OS, though.

For now yes. There is a way to handle this but it will take more work.

Yes, we test on Windows and I have used it locally on Mac.

No, the runtime is bundled.

At this time, no not without spinning up a VM. But we are looking into using BinaryBuilder2’s infrastructure to do this kind of thing.

Yes, the academic license.

Thank you so much for answering all of my questions.

Follow-up questions:

  • Do you have a link to the text of the academic license?
  • Does the package FMUGeneration support vectors or arrays as inputs or outputs, as introduced with FMI 3.0?
  • Would it be possible to export a model that uses the DAE solver DFBDF?

To answer my first question: dyad-lang/LICENSE.md at main · DyadLang/dyad-lang · GitHub

Not yet.

Not yet.

1 Like

Windows to Linux should be pretty easy with wsl, right?

Does anybody else find this confusing/contradictory? :thinking:

Well, my interpretation is, that if you create an FMU and distribute the FMU, you are not distributing Dyad. You are just distributing the output of a compiler.

And yes, it would be nice if the license for the output of the compiler (which will include some shared libraries) were clearer. But for me, it is clear enough, if the output is used for educational purposes, I am allowed to distribute the FMUs.

I might ask the advisor of our University if that is clear enough, or if we need further clarification from JuliaHub.

But yes, let’s get that clarified in license text. Sorry that does need more clarification and we will get back to you on this.

Does this imply that it is not currently possible to run two or more Julia-generated FMUs in the same primary simulation due to the limitation on initializing multiple runtimes in the same application process?

IIRC, that restriction has recently been removed.

I understood that the threads limitation (the second bullet here) was probably fixed (though I can’t find this clearly stated anywhere, and the documentation still contains the restriction). However, the other limitation regarding calling jl_init() more than once in an application lifetime I can’t find anything about. Would be great if that had been dealt with… probably need a documentation update to reflect these.

If anyone can clarify the state of both of these, that would be appreciated.

1 Like

It directly has a hack in the symbol generation of the Dyad FMU generator. Yes, we should probably document that this works.