ModellingToolkit.jl?
ModellingToolkit.jl?
Well, ModellingToolkit cannot produce C code for embedded systems. And it has no graphical interface like Simulinkā¦
3 Likes
My two cents here. Notice that everything is related to algorithms used in the analysis of satellites.
I really do not understand the title Fortran still has of being the best language for high-performance numerical algorithms. I do know that it is not the language but the compiler and the optimized libraries. Am I right?
Julia can use MKL pretty easily and transparently. I have ported several Fortran algorithms to Julia. To name a few: SGP4, NRLMSISE00, JB2008, and IGRF. In all implementations, Julia using MKL was faster than Fortran. Ok, it was not by a considerable margin (something between 2 to 10% depending on the case). Notice that it does not mean that Julia is faster, but that I was not capable of configuring the Fortran compiler to produce a more optimized code 
The point is: I still do not see that substancial Fortran improvement in my area. For that kind of algorithms, Fortran and Julia can be considered equal in terms of performance.
I tend to agree that you need to take more ācareā when coding high-performant code in Julia than you need in Fortran because the latter is compiled, and a lot of problems are caught in compilation time. However, in Julia, you have an interactive language that makes prototyping much faster.
Finally, DifferentialEquations.jl is unmatched IMHO, including MATLAB. For a control engineer, there isnāt a better ODE solver for simulating complex control problems
10 Likes
Thatās what I suspected. I was pointing out that you wrote that Fortran canāt be compiled to a small executable.
āThere is a disadvantage to Fortranā <=> āFortran has a disadvantageā
1 Like
Agreed, surely these huge projects/packages will be alive for a long time. But Matlab is in danger because (I think) it has been used as an educational platform, and from there many developers arise. A lot of people already moved to python there, even it being a patchy solution for scientific computing. But if at some point they go free and change their business model, they may persist in that field too.
3 Likes
There is some support for generating C code with ModelingToolkit. See Automatic Conversion of Julia Code to C Functions Ā· ModelingToolkit.jl.
4 Likes
Sounds promising! So perhaps Julia can be used more seriously for control system development in a few years.
2 Likes
There are two sides on where Julia has advantages over other languages, as I see it.
From the programmerās perspective:
- Speed benefit - fairly obvious in comparison with interpreted languages, but IMO Julia can be āfaster than Cā. The speed advantage over C/C++/Fortran comes not necessarily from more efficient machine code for 1:1 translated programs but because high-level languages make it easier to explore alternative, potentially more efficient, computational approaches.
- Consistency of ecosystem. I donāt know the situation in Fortran, but in C++ thereās a multitude of linear algebra libraries, each with its own data types and interfaces. In Julia, unified array interface makes it much easier to write programs which work with any implementation.
- JIT and autodifferentiation enabled by it. Might not be a big deal for many, but at some point you might need to find the pressure in a fluid described by PC-SAFT equation of state, and itās so much more convenient to just use autodiff to get the Helmholtz energy derivative than to deal with it by hand.
- Type system and dispatch.
From userās perspective (or why would users care about a language used for software they use)
The use of numerical software in academia today requires creative approaches, as all āsimpleā problems are already solved. For that, itād be good to have a way to hook inside the computational process. That is true for simulations, at least, where I as user would like more tools to make steered simulations. If you look at LAMMPS molecular dynamics package, you see that the scripts that define simulations are written in a custom mini-language with conditionals, variables, ability to execute shell scripts. That evolved from initially a simple configuration file structure which only had lines of the form
[option name] [parameters]
HOOMD-Blue developers chose to use Python for simulation control from the start. Interfacing with Python allows users to add arbitrary control elements to the simulation (so they may publish faster 
). But parts written in Python would be slower than the core written in C++ with the emphasis on GPU support. An MD package written in Julia could potentially make user-defined hooks first-class (while still being written in a high-level language). So, I think Julia may gain some popularity in that field if some group writes a reasonably-featured and reasonably-performant simulation package.
11 Likes
There are plenty of large-scale Fortran projects with high-quality documentation, CI, and code coverage. The documentation tools are also abundant for a Fortran codebase. Ask for examples in the Fortran discourse forum. Letās keep misinformation out of an already contentious topic. Regarding array ranks, there is select rank construct in modern Fortran (That is why the OP puts an emphasis on a comparison with modern Fortran).
2 Likes
When I was referring to documentation, I mean the possibility of writing the documentation as a comment above the function, accessing it from the REPL (and by a click on vscode), and get that automatically published in the docs, with the examples tested. Of course the quality of the docs are on the hands of the developers, and there is also abundant bad documentation in Julia packages. But I am not aware that Fortran has this kind of tools:
julia> """
```
f(x::Int)
```
Multiplies an integer by two.
### Example
```jldoctest
julia> f(1)
2
```
"""
function f(x::Int)
return 2*x
end
f
help?> f
search: f fd for fma fld fld1 fill fdio frexp foldr foldl flush floor float first fill! fetch fldmod filter falses finally foreach
f(x::Int)
Multiplies an integer by two.
Example
āāāāāāāāā
julia> f(1)
2
3 Likes
Iām not sure if this information is written anywhere (@giordano @ericphanson ?) but there is a JuliaCon 2021 talk measuring the amount of documentation and testing in Julia packages. Code, docs, and tests: what's in the General registry? | MosĆØ Giordano, Eric P Hanson | JuliaCon2021 - YouTube
2 Likes
Thanks for linking our talk!
We also wrote a blog post: Code, docs, and tests: what's in the General registry?
6 Likes
Iām sorry my post came across as spreading misinformation, I did try to deliberately temper my language, though I agree with you on the point about CI (a quick Google search would have pointed me in the direction of how to set this up, though it does look slightly more complicated than with Julia, given that there is no de-facto standard Fortran testing framework). Iām happy to edit the original post if you believe that would help avoid misinformation spreading!
I donāt think select rank is there in terms of flexibility, though. Correct me if Iām wrong, but it only effectively works with dummy arguments, no? That makes it hard to dynamically āallocate ranksā, if you will. Parametric types in Julia and indexing with splatting look like they could remove a lot of the boilerplate Iād need for the same behaviour, though I still have to try this. I agree that my example of various ranks is probably not the best for showcasing how much boilerplate you tend to have with Fortran, it was just the first thing that came to mind, since I had the experience of being frustrated with select rank limitations.
I hope I didnāt come across as too condemning of Fortran. I still love the language, and simply thought to share my perspective as someone coming from Modern Fortran and trying out Julia.
2 Likes
Thank you very much.
I can think of three advantage of Julia.
-
Interactive. Basically I if I wrote a subroutine or function, or a module, I can immediately test it and check it. In Fortran I can also do that, write a small drive code to do testing. But in Julia or Pyhton, it is slightly easier.
-
If I were to develop a software available to people, it might be more easy to use Julia. Eg, if I need to solve differential equations, perhaps in Julia I just need to use the differential equation jl package. But in fortran, I have to instruct people how to install some differential equation Fortran libraries, perhaps with Cmake, it might be difficult for some users who just want a button that automatically install everything they need.
-
The results are consistent. Just say on 64 bit machine, I believe the same Julia code should give same results over all platforms and machines. But in Fortran, if the code is not well written, like some variables are not corrected initialized and then be used etc, gfortran and Intel Fortran may behave differently, some code may compile on intel Fortran but not so on gfortran. etcā¦
However, modern Fortran is also developing. Modern Fortran code is nothing like the cumbersome F77 code at all. Actually I do have a feeling that the same code, if written in good modern Fortran, and good Julia, they can look very similar.
If Julia can optimize better, that is, more easier for people to write code can run just as fast as Fortran did, it can become more and more popular.
On the other hand, I do feel since Julia, Python, R, Matlab, those language are so similar in the sense that the way they manage packages, interact with users, easiness to write code, whichever have the best performance may become the most popular at the end. My feeling is that Python seems have reached its limit, and Julia is just begun.
7 Likes
Long time (+20y) Fortran programmer here. I am a scientist. Never got into Matlab/Python/whatever, but Julia blew my mind. Now I use it a lot.
The biggest advantage of Fortran is protability. The Fortran standards comitee is very respectful withold standards. I can take an analysis code of a paper I wrote 15y ago, compile it and run it and obtain the same results written in the paper. Without changing a single line of code, without having to install this/that in a container. Just take the latest Fortran compiler and use it. It will work.
Each time that I see some heated discussions here about something that is basically trivial, I have the feeling that Julia will not have this level of portability. At some point Julia v1.X will be āoldā, all your old code will be incompatible, and you will have to run it in a container if you are lucky. If this really happen, I will probably move away from Julia and come back to Fortran. My work is in science, and I simply cannot afford to rewrite things that work perfectly because of a estilistic fashion.
I think that sometimes CS (or people that work in software developing, but are not scientist), do not realize how important for reproducibility is to have some guarantee that your code will run in 10-20 years.
In any case I think that both Fortran and Julia can coexist. Each is good for its own things.
20 Likes
Project.toml and Manifest.jl allow people to reproduce environments. As long as packages specified in those files remain in a repo, and Julia binaries remain compatible with future computers/architectures, reproducibility should not be a problem, I think.
2 Likes
I like that Julia just lets have me all versions installed I need and want, without any problems so far. I still have a Julia 0.3 service running on a system where new versions are installed and got no problems. No need for containers or anything advanced.
So, the different Julia versions/environments can still coexist on a single OS environment.
For me a big Julia advantage (not over Fortran, but other systems, e.g. R).
3 Likes
Well, with Julia 2.X/3.X in 15 years time, the sintax might have changed, and I seriously doubt that you could take a 15y old program and run it as it is. Not to speak about what will happen when github/git is no the tool of choice (the question is not if these tools will disappear, but when will they disappear). There are other thousands of things that can happenand I can think of. Then there are other millions of things that will happen and I cannot think of.
The level of portability required for scientific work is extremely demanding, and has to survive fashion, new technologies and many other things. Fortran code will run as it is in 15y. Julia codeā¦ I seriously doubt itā¦ Fortran is based on ASCII and a solid standard. Julia depends on a Huge ecosystem, that will eventually change much faster than the ASCII standard.
3 Likes
I also like Julia reproducibility. Unfortunately it is so amathing because i depends on many things that will eventually be improved. Then your old legacy code will find a hard time to work.
Man, I always wished Julia followed the ASCII model. 128 characters ought to be enough for everyone, right?
2 Likes