Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modelica

modelica.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Modelica

#101

Post by ghc »

brap wrote: post #81

I don’t know what this is. There’s not a single example on the landing page. There’s not a single example on any of the main links from the landing page. But the landing page does have a merch store so you can buy mugs and hoodies and look at huge company logos of “organizational members”, whatever that is. You made something. Show me what you made. I’m probably not going to spend more than 30 seconds trying to figur…

I think it's actually pretty modern. Compare to the USB consortium:

https://www.usb.org

or PCI-SIG:

https://pcisig.com

Or maybe the design language is too modern...did you mistake it for a startup project rather than a 25+ year old industry standard?

It's interesting to contemplate the idea that being too modern might have a detrimental effect on perception and expectation. How would you have reacted to the site design circa 2018? http://web.archive.org/web/20180214180117/https://www.modeli...

Re: Modelica

#102

Post by constantcrying »

The concept of FMUs is pretty interesting if you work in simulation, but I was surprised how terrible the third party support is.

There is not a single third party way to generate a Model Exchange FMU for Linux, using anything but the very badly designed C reference FMUs or some commercial project. Even Matlab has poor support for it.

Re: Modelica

#103

Post by constantcrying »

brap wrote: post #81

I don’t know what this is. There’s not a single example on the landing page. There’s not a single example on any of the main links from the landing page. But the landing page does have a merch store so you can buy mugs and hoodies and look at huge company logos of “organizational members”, whatever that is. You made something. Show me what you made. I’m probably not going to spend more than 30 seconds trying to figur…

Because it is not for you.

It is for people simulating complex multi-disciplinary systems, who need a way to describe, bundle and exchange the behavior of a system.

Re: Modelica

#104

Post by [deleted] »

alhirzel wrote: post #31
vsskanth wrote: post #27

This is a pretty niche acausal language, and is used extensively in Motorsports (F1, NASCAR) for real-time simulation on the driver simulator. The language spec is open source but there many commercial compilers, Dymola is the most popular. I code in this language extensively and its acausal nature is extremely powerful. It makes your models highly composable, you can basically assemble a mechanical system like a bun…

Agreed on all fronts - and I bet you're doing interesting work! I feel like acausal modeling environments are also much like symbolic computer algebra systems (because they are basically applied CAS...)

[deleted]

Re: Modelica

#105

Post by ChrisRackauckas »

anothertroll123 wrote: post #90
michaeltiller wrote: post #73

Earlier quoted context omitted.

Well most Modelica tools generate C code. I think all of them also generate FMUs (lookup Functional Mockup Interface, if you don't know what an FMU is). Some FMUs are source code FMUs (suitable for running on HiL hardware, for example). But it sounds like you might be talking about autocoding of an embedded controller. In that case, I'm not aware of any tools with that target. Part of this is because Modelica can be…

Interesting. Can you suggest one or two in particular? I'd be curious about that code. And yes, I'm talking about autocoding of an embedded controller. Which also means the C code has to be ready for that (hard real time, carefully controlled calls to libraries, no heap allocation, etc.) Right now Simulink embedded coder can be (and is) used to generate production code for all sorts of aerospace vehicles (rockets/spa…

The Julia tools can target embedded devices through LLVM if it has an LLVM compiler. This is one of the big reasons for the juliac ahead-of-time compilation functionalities recently added to Julia v1.12, it's for the JuliaSim/ModelingToolkit.jl simulation environments to target embedded devices in this manner. We'll be sharing something on this at the MODPROD OpenModelica conference early next year.

As for C code, we're working on it through JuliaSim. JuliaSim's modeling language is very similar to Modelica in some aspects (Mike Tiller who is in this thread and the author of many of the main Modelica teaching tools is also one of the creators of this language), though there were some breaks which were required in order to make better downstream integrations with the Julia stack and in order to modernize development workflows (integrations with package management, some new langauge features, etc.). Part of what we're trying to do is solve exactly where Modelica got stuck: embedded code generation and other "non-GUI workflows" (CI/CD for example) and making those first-class integrated with the declarative modeling language. There's still a good amount of work to do but we've already started trickling out some results in this direction and running workshops on the tools at Modelica conferences.

Re: Modelica

#106

Post by pkoird »

tpoacher wrote: post #100

People seem to be comparing it to Simulink, but to me the language seems to have more in common with matlab / octave's symbolic package / python's sympy. Any idea if that's the case?

The difference you are pointing to is the acausal vs causal description. In Simulink (Causal), you have to describe what causes any changes in the system. For example, to model Ohm's law, you'd write something like I=V/R. Which translates to the current obtained when some potential difference is applied across a resistor. So I is a function of V in this respect and you can say V causes I in R.

In Acausal systems like modelica, it does not matter whether you write V=IR or any alternate formulation. You simply provide the description and it is up to the compiler to obtain the relevant set of equations that can be fed into the ODE solver. The advantage being that you spend less time fitting your problem into the causal framework required by Simulink or alternates where, when you change your model, you end up doing significant rewrites.

TL;DR: Causal descriptions take more time to arrange as compared to Acausal.

Re: Modelica

#107

Post by anothertroll123 »

ChrisRackauckas wrote: post #105
anothertroll123 wrote: post #90

Earlier quoted context omitted.

Interesting. Can you suggest one or two in particular? I'd be curious about that code. And yes, I'm talking about autocoding of an embedded controller. Which also means the C code has to be ready for that (hard real time, carefully controlled calls to libraries, no heap allocation, etc.) Right now Simulink embedded coder can be (and is) used to generate production code for all sorts of aerospace vehicles (rockets/spa…

The Julia tools can target embedded devices through LLVM if it has an LLVM compiler. This is one of the big reasons for the juliac ahead-of-time compilation functionalities recently added to Julia v1.12, it's for the JuliaSim/ModelingToolkit.jl simulation environments to target embedded devices in this manner. We'll be sharing something on this at the MODPROD OpenModelica conference early next year. As for C code, we…

Thank you! Sounds like this is still in works but I'll start following its progress.

Re: Modelica

#108

Post by xgdgsc »

wolvesechoes wrote: post #79
alhirzel wrote: post #19

Earlier quoted context omitted.

Another up-and-coming solution is Julia's simulation ecosystem [1]. It is powered by the commercial organization behind the Julia programming language, which has received DARPA funding [2] to build out these tools. This ecosystem unifies researchers in numerical methods [3], scalable compute, and domain experts in modeling engineering systems (electrical, mechanical, etc.) I believe this is where simulation is headed…

"Another up-and-coming solution is Julia's simulation ecosystem" Still not comparable with Modelica that has proper specification, including graphical representation of models.

There' s a Chinese company also using Julia and Modelica https://www.tongyuan.cc/product/MWorks . They have projects like https://github.com/Suzhou-Tongyuan/syslab-deploy using https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-... .

Re: Modelica

#109

Post by tpoacher »

pkoird wrote: post #106
tpoacher wrote: post #100

People seem to be comparing it to Simulink, but to me the language seems to have more in common with matlab / octave's symbolic package / python's sympy. Any idea if that's the case?

The difference you are pointing to is the acausal vs causal description. In Simulink (Causal), you have to describe what causes any changes in the system. For example, to model Ohm's law, you'd write something like I=V/R. Which translates to the current obtained when some potential difference is applied across a resistor. So I is a function of V in this respect and you can say V causes I in R. In Acausal systems like…

So ... the answer is "yes"?

In which case, isn't comparing it to Simulink instead of Sympy a bit ... odd?

It's like coming up with a Functional language, and choosing to compare it to Java instead of Haskell.

In any case, interesting language. It would be interesting to see a proper comparison against sympy / symbolic.

(I spotted this, but it's not really a comparison https://pmc.ncbi.nlm.nih.gov/articles/PMC7924524/ )

Re: Modelica

#110

Post by mscuttari »

Hey folks! If you're into trying out bleeding-edge technologies, check out the MARCO compiler. We're focusing on optimizing large-scale systems, and it's already showing significant improvements compared to existing solutions. That said, we're still in the early stages: language support needs to grow, and for now, there's only a command-line interface. But hey, it's open-source, so contributions, feedback, or feature requests are more than welcome!

Here’s the GitHub repo: https://github.com/marco-compiler/marco

And here’s a link to the latest published results: https://ecp.ep.liu.se/index.php/modelica/article/view/909

Would love to hear your thoughts or ideas!

Post reply on HN