Julia and the satellite Amazonia-1 (2020)(discourse.julialang.org)
discourse.julialang.org
Julia and the satellite Amazonia-1 (2020)
https://discourse.julialang.org/t/julia-and-the-satellite-amazonia-1/57541
28 comments
I'm glad to see some of Ronan's work get a spotlight. He was one of the early DifferentialEquations.jl users and discussions with him + bug reports really helped guide the SciML project in the right direction. He's one of those Julia community members that really makes OSS development a fantastic experience. You can trace a lot of the 2016-2017 design choices around callbacks to helping his satellite control use cases. Now, that satellite is up there. It's a really nice and personal example of how this "Julia Generation 3" community has grown and matured over the last half decade.
SatelliteToolbox.jl[0] (one of the packages developed by the post author) is one of my most-used Julia packages! It's great for (among many other things) working with TLE orbits and presents a really nice interface for converting between all the different Earth-fixed and Earth-centered-inertial frames, which is generally a huge hassle. Ronan has also been very friendly to PRs on Github which is always nice. Awesome to see this mission come together!
[0] - https://github.com/JuliaSpace/SatelliteToolbox.jl
[0] - https://github.com/JuliaSpace/SatelliteToolbox.jl
I didn't put a (2020) in the submission title as the post was only created 6 days ago. Did I miss something here? I'm sure it was editorialised for a reason but I can't figure it out, sorry if I'm being stupid.
And the post couldn’t be older since it has a photo from a satellite that was launched this year. My guess it is some automated task that got confused because the post is in a forum, not a regular blog post with a publishing date.
I just created an account to tell you my guess: The timeline to the right of the post shows "Mar 20", for the 20th of March (2021). I think some moderator misunderstood that as March of 2020 and changed the title.
As an administrator at Julia's discourse, I'd be really curious if this was the reason. Discourse's default "short date" format is super problematic. By default, they display something from 5 days ago as `Mar 20` and something from a year ago as `Mar '20`. We've changed that to have the year+ old posts display as `Mar 2020`, but maybe we should also change the recent display to be something different; maybe `20 Mar`? The UI doesn't give us too much space, unfortunately.
> The UI doesn't give us too much space, unfortunately.
I don't see where it's cramped, there's a lot of room on my screen.
Another option is "June 20^{th}"
I don't see where it's cramped, there's a lot of room on my screen.
Another option is "June 20^{th}"
Between this, BNDES (Development Bank) and Bacen (Central Bank, its "Fed"), it seems like Brazil's public service is a Julia hotspot.
The Brazilian academics favors open source over commercial software (the most well ranked universities in the country are free, and many student cant't afford to pay license fee).
So it doesn't come as surprise egresees uses Julia, R over the paid counterpart.
So it doesn't come as surprise egresees uses Julia, R over the paid counterpart.
Not really. julia is niche at the best in Brazil. Python largely dominates the scene
Brazilian institutions used to love FORTRAN and Matlab. Maybe Julia was more familiar to their teams somehow.
Did Lua ever have a corresponding long march through the institutions?
I don't think so. For example: Lua was supposed to be the official language for interactive broadcast TV apps in the early 2000s, but it lost to Java due to IT consulting firms pressure.
This post illustrates one of the reasons why I love Julia.
When talking to Python colleagues about Julia one response is "well, but I don't really care about performance _that_ much".
The thing about Julia is that you can code without caring about performance (and the performance will be Python-like). If later on it turns out that you DO care, you CAN optimize it. With Python you don't have that option, as in Python "optimizing" means using cython/numba over numpy arrays, and all the limitations inherent to that approach.
This is obviously good, and I'm not even sure what the trade-off is. What am I losing?
When talking to Python colleagues about Julia one response is "well, but I don't really care about performance _that_ much".
The thing about Julia is that you can code without caring about performance (and the performance will be Python-like). If later on it turns out that you DO care, you CAN optimize it. With Python you don't have that option, as in Python "optimizing" means using cython/numba over numpy arrays, and all the limitations inherent to that approach.
This is obviously good, and I'm not even sure what the trade-off is. What am I losing?
Python isn't the competition for satellite image processing. That is very much a C++ world. The existing code is already so absurdly optimized that you're not going to compete on that basis. Where you can compete is the code is also absurdly complex and it's very hard to find developers who can productively use it. If Julia can get close to similar performance but be much easier to understand, that could be a huge boon.
Someone needs to be a first mover, though. The unfortunate thing I've seen in the satellite world is companies think they can take Java developers and teach them C++ and the transition will be seamless. It definitely isn't, but the basic OO concepts and syntax is similar enough that the idea is easy to sell. Trying to sell these huge enterprise and government systems on a programming language that hasn't even existed for a decade won't be easy, in contrast, no matter how simple and no matter how performant it is. Somebody is going to need to step up and just do it, with or without some huge corporate or government sponsor.
Someone needs to be a first mover, though. The unfortunate thing I've seen in the satellite world is companies think they can take Java developers and teach them C++ and the transition will be seamless. It definitely isn't, but the basic OO concepts and syntax is similar enough that the idea is easy to sell. Trying to sell these huge enterprise and government systems on a programming language that hasn't even existed for a decade won't be easy, in contrast, no matter how simple and no matter how performant it is. Somebody is going to need to step up and just do it, with or without some huge corporate or government sponsor.
You said "The thing about Julia is that you can code without caring about performance (and the performance will be Python-like)."
This is not my experience. Even if you code without caring about performance it is way faster than Python. Also, it is not any harder to code in than Python. It is as high level if not more.
This is not my experience. Even if you code without caring about performance it is way faster than Python. Also, it is not any harder to code in than Python. It is as high level if not more.
> This is not my experience. Even if you code without caring about performance it is way faster than Python.
It is very usecase dependant. If your Python code is writing lots of loops and scalar processing then naive julia code will trash it. but if it is basically spending all its time in numpy/BLAS routines then they will be comparable. and Julia will looks like its not worth it, since compile time makes it overall slower etc.
> Also, it is not any harder to code in than Python.
If you already know Python then it is easier to use what you know. Furthemore, if you already know Python (or even more so Matlab) it can cause some stumbling blocks. Some idiomatic code in other languages, (like writing everything as big array operations), is unidiomatic in julia (since it causes a lot of allocations tht you don't need)
It is very usecase dependant. If your Python code is writing lots of loops and scalar processing then naive julia code will trash it. but if it is basically spending all its time in numpy/BLAS routines then they will be comparable. and Julia will looks like its not worth it, since compile time makes it overall slower etc.
> Also, it is not any harder to code in than Python.
If you already know Python then it is easier to use what you know. Furthemore, if you already know Python (or even more so Matlab) it can cause some stumbling blocks. Some idiomatic code in other languages, (like writing everything as big array operations), is unidiomatic in julia (since it causes a lot of allocations tht you don't need)
Yeah, that's often the case but I wanted to make a conservative claim.
Two personal examples where Julia turns out to be much much faster than Python without me having to do anything but the most naive implementation:
- order of 10 float arrays with order of 1_000_000 elements each. Broadcasting an element-wise function in Julia or just doing a for-loop in Julia is way way faster than a pandas operation like col1 * col2 + col3 etc.
- the first time I tried one of Julia's optimizers (I think Optim.jl) it took 1ms on my problem. Sci-kit took 200ms. That's crazy.
Two personal examples where Julia turns out to be much much faster than Python without me having to do anything but the most naive implementation:
- order of 10 float arrays with order of 1_000_000 elements each. Broadcasting an element-wise function in Julia or just doing a for-loop in Julia is way way faster than a pandas operation like col1 * col2 + col3 etc.
- the first time I tried one of Julia's optimizers (I think Optim.jl) it took 1ms on my problem. Sci-kit took 200ms. That's crazy.
> Julia is that you can code without caring about performance (and the performance will be Python-like)
Typically unoptimized Julia is comparable to Python glue + optimized C (e.g. numpy).
Typically unoptimized Julia is comparable to Python glue + optimized C (e.g. numpy).
Ronan's blog. Interesting stuff:
https://www.ronanarraes.com/main/
https://www.ronanarraes.com/main/
Off-topic, but I'm always amazed at how massive Sao Paulo is. I remember visiting a museum there - I think it was the MASP - and there was this sprawling installation of a satellite view of the city that you could walk over. I walked, and walked, and walked and it felt like I could never reach the edge
Amazonia-1 was put in orbit by PSLV launch from SHAR this year (2021). The annotation (2020) is wrong.
https://www.space.com/india-launches-amazonia-1-satellite-18...
https://www.space.com/india-launches-amazonia-1-satellite-18...
See my comment above. I'm not sure why it was changed but hopefully one of the mods can change it back.
Very cool thread, and encouraging to see that they could open-source a good bit of the satellite code.
I also found a press release on the Julia Computing website:
https://juliacomputing.com/case-studies/BrazilNationalinstit...
But the forum link above seems more informative and the software architect has answered questions within the thread.
https://juliacomputing.com/case-studies/BrazilNationalinstit...
But the forum link above seems more informative and the software architect has answered questions within the thread.