[ANN] Dyad: A New Language to Make Hardware Engineering as Fast as Software

Package Announcements
, , , ,
1

JuliaHub is happy to announce Dyad, a new language to make hardware engineering as fast and easy as software engineering! Check out the release blog post!

What is Dyad in a nutshell?

It is a declarative physical modeling language, allowing the easy construction of complex multiphysics models by piecing together components from the provided model libraries (or your own model libraries!). It has a 1-1 relationship between code and graphical representations, which means the same model can be inspected and interacted with in both GUI (coming soon) and code. For the coding interface, JuliaHub has released the Dyad Studio extensions for VS Code, which offers easy interactions with the compiler, static analysis to ensure correctness of physical models, and ease of authentication into the JuliaHub registries for models and launching large-scale jobs on clusters. That last part is essential for some of our big differentiators, as you can build a big model on your computer but, with a click of a button, launch of a big multi-GPU job on the cloud to train a surrogate of your model for quicker inspection!

How does this relate to Julia?

You might think, oh no the JuliaHub people are working on a different language, not Julia? Well Dyad is actually quite related to Julia! The Dyad compiler lowers to Julia code, so if you know Julia SciML packages DifferentialEquations.jl and ModelingToolkit.jl you’ll feel right at home with its lowered representations. In addition, Dyad contains and interface for “custom analyses”, which means you can write dispatches in Julia which are then exposed as actions in the Dyad language and the coming GUI. Thus if you have some new fancy scientific machine learning workflow you’d like industrial companies to easily make use of, adding a little bit of Dyad bindings to your package suddenly exposes your new tools in these interfaces!

Why is a new language needed here?

There are a few reasons why we needed to create a new language for this. First of all, in order to achieve this goal of having the same code be both the backing of a graphical environment and be an accessible representation for modeling, it needs to be a declarative language. You can’t say “run this Turing machine in order to figure out how many resistors there are” if you want a GUI to be snappy! On top of that, we wanted to ensure that we could build responsive tooling that could perform static analyses instantly to alert about problems with units and incorrect physical corrections. This means that, while there are some declarative DSLs in Julia that are similar (notably @model macro in ModelingToolkit.jl), moving this to be a Typescript-defined declarative language that lowers into Julia makes it so we can achieve these goals.

But all of the imperative behavior takes place in Julia. You adding new functions/operators, new analyses, data handling, etc. is all done by writing extensions in Julia. Also, the Dyad packages are Julia packages, but with a few extra requirements, and as such it also uses Pkg for all of its dependency management. Thus if you’re a Julia developer, then you’re already suited to be a Dyad developer!

What’s Next?

We have a lot more that is coming soon. In particular:

  • New tooling around agentic and generative AI for modeling
  • Targeting embedded systems
  • The GUI
  • SciML model discovery analysis pipelines
  • Model-predictive control
  • Model libraries: multibody, HVAC/fluids, etc.

So much more is coming soon. Stay tuned!

Where can I get more information?

Check out our documentation:

and get subscribed to our newsletter as we will be releasing a series (/barrage!) of blog posts as many things Dyad related are about to be released!

24 Likes
2

This seems pretty neat, kudos and good luck to everyone involved!

For anyone (else) who wanted to see a sample of the GUI and the corresponding code behind it, one of the tutorials has a pretty nice example.

Also, for anyone (else) that’s curious about licensing and missed the last part of the blog post:

We have chosen to publish Dyad Studio under a Source Available license. This allows us to make the code publicly available on GitHub and people can use it for free for educational and non-commercial personal purposes, with licenses available for commercial use. In addition, Dyad’s standard libraries are BSD3 open source licensed to enable open bug reporting and rapid improvements by community contributions.

- so, more “closed” than most things in Julia (at least that we publicly see and get to use), and more open than most things that are roughly in this space.

I’m really tempted to drop other things and try this out, to see what it feels like in practice :grinning_face: But I’ll defer it and just subscribe to the updates for now.

1 Like
3

So what is the relationship between MTK and Dyad? Will MTK become depreciated and shall be replaced by Dyad? Or will both receive continued improvements?

1 Like
4

That is accurate and a very good articulation of what we aimed for. There is lots of commercial software in Julia today, but it is not visible as you pointed out. We also feel that toolchains do need to have openness for wide adoption, but at the same time we do need a commercial model to sustain it over long periods.

1 Like
5

Dyad emits MTK, so it is a layer on top of MTK, and thus both will co-evolve. Of course, we also want to explore at some point what native compilation looks like and a lot of that will depend on what the users want.

1 Like
6

This post mention catching unit errors, but a brief skim of the docs didn’t tell me much about Dyad’s approach to units? Is unit support built in? Based on Unitful? Something that can be done by importing a package?

7

Unit support is built in. It’s not based on Unitful. It’s not done through multiple dispatch because that’s not the right level to do unit checks correctly. If you make your number types all Unitful.jl values, then every single piece of arithmetic, every single time a function is called, is always checking the units. This either has a high run time or compile time burden, and it’s usually a high run time burden because most models will have many units and thus you’d have Any-eltype arrays (DynamicQuantities.jl can make this be type stable, at a computational cost). But that level is not necessarily what you need: you need to check whether your physical equations are unit correct, and if they are correct, then you can just generate lean code knowing that the equations are fine. This makes the code simpler while also making it easier to do things like target C for embedded devices.

So instead, this is the kind of stuff then done at the TypeScript level, for example making sure that the voltages are not connected to masses, and giving instant linting feedback in the VS Code extension.

Note that the unit implementation is not complete right now and there’s more coming with that, but at least that should be clear as to why this is elevated to a language / compiler level pre-Julia.

8

MTK is the compiler for Dyad. The major push of improvements to MTK has been all funded based on Dyad’s development. In other words, it’s the exact opposite: MTK is only able to exist because of Dyad.

3 Likes
9

Interesting to see the “source available license”. Could this be used for other projects as well or is its use limited to JuliaHub ? Also, what is the difference to GPL/AGPL ?

We had good experience with AGPLv3 based dual licensing (TetGen mesh generator) - the commercial licensing brought quite a bit of revenue.

10

*GPL licences grant the user explicit rights to use, modify, and redistribute the code within the parameters set by the license, which are mostly that distribution of derivative works must make source code available under the same or a compatible license. Beyond that, you’re allowed to use the software for anything you wish, commercial or otherwise.

Looks like the full Dyad license agreement is the JuliaHub EULA […]

Correction: as pointed out by @viralbshah below, the Dyad Source Available License is here: GitHub - DyadLang/dyad-lang: The Dyad Language Kernel. It’s a slight modification of PolyForm Strict License 1.0.0 – Polyform Project. Some relevant lines:

license […] to do everything you might do with the software that would otherwise infringe the licensor’s copyright in it for any non-commercial use

does not include distributing the software or making changes or new works based on the software.

Use by any state, local, or national government, including use for research and development purposes, is considered a commercial purpose and not permitted.

So, personal, non-commercial use and not-for-profit education/research is OK, however, compared to *GPL licenses, there are a lot more restrictions on what you can do with the code, and the purpose of the license is different. The point of *GPL is to ensure that the source code is always available to whoever is installing and running software built on/with the code. The point of the source available license is presumably to balance openness against JuliaHub’s commercial interests.

I’d be curious how this works if/when you start receiving contributions back from your users. I suppose they must also agree to you selling a commercial license to code that includes their contributions without them being compensated. That’s what CLA’s are for I guess. (Off-topic, so let’s not take this tangent and run with it.)

11

We adopted the PolyForm strict, but customized it a bit for our needs: https://polyformproject.org/. The website discusses the rationale and design.

12

The JuliaHub EULA is our commercial license. The Source Available license is the license in the dyad-lang repo here: GitHub - DyadLang/dyad-lang: A collection of TypeScript packages to implement various aspects of the Dyad language.

Like I said above, it is an adapted version of PolyForm Strict, which is a choice we made.

The Dyad standard library is BSD-3 licensed, and it derives from the OpenModelica Standard Library. All the underlying ModelingToolKit and SciML Julia packages are MIT licensed.

Like you said, we would need a CLA in order to accept contributions. We have just put the release out there, and we’ll put infrastructure for CLA shortly. Please reach out to us on #dyad on the Julia slack for any questions or discussions.

13

Thanks for the correction, I’ll edit my post.

Just to explain: the dyad-lang repo wasn’t public when I was flipping through this, and the other non-BSD Dyad repos only have a generic “All rights reserved” notice (e.g., GitHub - DyadLang/DyadData.jl: Interface for interacting with datasets in Dyad). The only pointer I could find to an actual license was in the Dyad Studio VSCode extension, which links to the JuliaHub EULA (License Agreement | Visual Studio Marketplace), hence my inference in the post above.

14

We realized that we had forgotten to flip the bit on that repo, until I saw your comment. :slight_smile:

1 Like
15

Non-commercial use also includes use by any not-for-profit educational institution. Use by any state, local, or national government, including use for research and development purposes, is considered a commercial purpose and not permitted.

Can you clarify how university research funded by government grants fits into this?

16

That would be usage at an educational institution / university, and hence free.

1 Like