With radio astronomy, we can look across many light years of distance and see incredible details
such as the chemical makeup of a given region. Kevin Vincent and Rodrigo Tabar from ICRAR are
using the world's fastest supercomputer, along with some sweet Python, to process the equivalent
1,600 hours of standard definition YouTube video per second. This is Talk Python to Me,
episode 257, recorded March 26, 2020.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter
via at talkpython. This episode is brought to you by Linode and Clubhouse. Please check out what
they're offering during their segments. It really helps support the show. Kevin Rodrigo, welcome to
Talk Python to Me. Thanks, Mike. Great to have you guys both on the show. This topic is something that
I'm both fascinated with and actually not very knowledgeable about, so it's awesome. And it has
a really cool bunch of Python going on as well. So I think we're going to have a lot of fun talking
about radio telescopes and just processing ridiculous amounts of data with it.
Yeah, yeah. I think we were talking
with Kevin about this the other day that we kind of lose sight of how big these numbers are, because
if you are always within this realm, you don't realize that this is actually pretty big.
Yeah, that's a bit of an understatement. So we'll definitely dig into all the data
and everything that's going on. It's pretty impressive. It's
certainly, well, I'll leave it until we get to it. But it's some crazy, crazy numbers that you
all are doing. But before we get into that stuff, let's just start briefly with how you each got
into programming Python. Maybe Kevin, you go first.
I did my degree in physics back in the UK and then sort of drifted around doing various languages.
I programmed in C, C++, Prologue, Lisp, Smalltalk. And from that, you can tell I'm quite old.
When I came to join ICRA in 2009, Python is this de facto language for an awful lot of astronomy. So
I learned Python.
Yeah. What was that learning Python experience like?
Piece of cake, really. It's much easier than Java and C++ because
the syntax is just so much cleaner.
Yeah, it is. And, you know, it sounds like you have experience with a lot of different languages,
right? Like Scheme, Lisp, Smalltalk, C++. There's a lot of different examples. And so,
you know, you come to Python and you're like, oh, this is a weird language. It doesn't have any line
breaks or it doesn't really love the synth, like a lot of syntactical elements in there. But
somehow...
Where do I put my semi-colons?
Yeah, I do.
Learning not to semi-colons took a while.
Yeah, I do find it funny that you can still write them if you just feel the need, you know?
You're like, I just put them at the end. It's going to be okay.
Yeah, praise be to IntelliJ or PyCharm because it tells you, you don't really need that.
Yeah, exactly. If you really need that comfort blanket, I suspect you could turn off that code
detection, code rule in PyCharm and just put the semi-colons. But you may not be accepted by your
fellow Python programmers.
From the bone.
It's right. That's right. Rodrigo, how about you?
Well, since very little, I always liked computers. So I decided to go and study a computer degree
without really knowing exactly what computing was about, like about programming and all.
So at junior, I started learning some languages and I became involved with astronomy. We had a group of
students who were doing collaborations with some observators. I'm originally from Chile. And in Chile,
there are many observatories because the conditions are so good for observing. So there was this group of
students doing collaborations with some observatories in Chile. That's how I got basically into the business.
So when I left uni, I moved into the European Southern Observatory headquarters in Germany. I worked over there for a couple of years and then moved here to ICRA in Australia to continue working in astronomy. In Python in particular, I started doing some more Python down here in Australia. I had done a couple of basic scripts before, but nothing much to it. And I really got into the weeds now.
Because we were heavily using Python here.
Well, yeah, that sounds really fun. And certainly Chile is one of those places where astronomy is, especially radio astronomy, right? Is that where Contact was filmed?
No, Contact was filmed in the US, in New Mexico, close to Socorro, south of Albuquerque.
It was set though, in like in that area, right? And that general, it was definitely South America somewhere.
Maybe some parts of the movie.
Arecibo, maybe? I think so.
Oh, yeah.
There might be a shot or two in Arecibo. That's in Puerto Rico? I forget.
Okay. Yeah, yeah, yeah. Okay. Puerto Rico. Yeah. Okay. So it's not exactly the same one, but there's definitely with the mountains there, there's a bunch of observatories, right?
Yes, yes. It's very heavy on the optical side as well. So for optical and radio astronomy, you have different set of requirements, if you want. For optical, you basically want like super, super clear skies.
Whereas with radio telescopes, you can have clouds on still observant. So Chile, in the north of Chile, there's a huge desert, which is very, very dry. That's perfect for optical astronomy.
Right, right, right, right. So yeah, I hadn't really thought about that. Of course, for optical stuff, the higher, the better, the clearer, the better.
What are the requirements for radio telescopes?
It depends on the frequency, the radio frequency that you're observing. If you are in the high frequencies is basically amount of water in the air. It's called PMW or PVW. I forget the term for optical astronomy is also for the lower frequencies of radio astronomy is our find the radio frequency interference, basically any device that is emitting radio frequency waves. So you want very isolated places for that.
Okay, I see. As we'll learn, you can measure things like water and stuff very far away with radio telescopes, right?
Yes, that's correct.
So I suspect having like water in the air is a problem. You don't want that. That's interesting.
I mean, it's how your microwave works, you know. A microwave agitates the water. It's the same sort of basic principle. In a millimeter band, that's why the ALMA telescope, which is in the Atacama Desert, as Rodrigo was saying, has to be so high.
So there is no moisture there. Whereas the stuff we tend to work on generally can be down at sea level, almost or a little bit higher.
Okay, interesting. And what do you guys do day to day? Are you both doing astronomy basically day to day? Or code for astronomy?
Yeah, code for astronomy, pretty much. I mean, most of my work is helping more hardcore astronomers do things faster.
So, for example, a group who were doing some optical work, it was taking 42 days to do something. They then passed it over to us and we got it down to 18 hours.
That's awesome. That means you can do so much more science, right?
Yeah. But there's a classic divide and conquer problem. Parallelize like mad.
Although most of our astronomy tasks are embarrassingly parallel.
We scatter and we don't really do a gather until the very end. That's it.
I see. So it's almost like you could almost do individual computation on a per pixel basis, maybe? Or the equivalent of a per pixel basis?
We tend to work in frequency channels more than pixels.
But yes, so we would just process one particular or one band of frequencies on one machine, another band on another and another on another.
Other work I do is quite a bit of machine learning work for detecting RFI, gravitational waves, doing corrections.
We're actually now moving some of our astronomy work into ocean wave investigations and trying to look at whether we can correct the swell heights.
So, you know, surfers know whether it's going to be a good day to go surfing.
Right. Okay.
Now, that would be a really unexpected consequence or outcome or capability from studying gravitational waves is better surf predictions.
They're just waves. It's a propagation speed that's different.
One's rather quick and one's not.
Yeah, I guess so.
Yeah, the whole gravitational wave detection stuff is some pretty cutting edge science and it's really interesting.
And it's cool that you're using machine learning to try to understand that.
We have a small group working on it.
We've got devices in the proper detectors.
So this is a very active area of research.
There's a lot of groups around the world working on this.
Yeah, I think it's kind of amazing.
There's a lot of stuff with gravity oriented things in astronomy right now.
We have the gravitational wave detection for the collisions of black holes.
We have the first picture of black holes in the last year and a half or so, whenever that was.
A lot going on around there.
Yeah.
And then, of course, the other thing is teaching.
Sure.
I guess if you're at a university, eventually, you might end up interacting with a student or two.
Very cool.
Unnecessary.
All right.
Rodrigo, what about you?
Well, kind of similar.
I'm a software person, right?
Who became involved in astronomy.
So I basically help astronomers to develop software in different languages for different purposes.
So not only for radio astronomy, but also for optical astronomy.
And also for, we have also a theoretical group.
So people who do simulations of galaxy formation and such.
So kind of all over the place.
And we, not only me, but all the people in the group we specialize kind of in this area of helping astronomers build the software, deploy it, optimize it, and so on.
How much do you end up helping them with standard software engineering things?
Like, hey, hey, I need to teach you source control.
This is Git and GitHub.
Let's spend an hour talking about that.
Or are they pretty much good to go?
Yeah, it depends on the generation, I would say.
So older generations are a bit harder to kind of, you know, move to that side.
But newer people, like younger people, then come with all those concepts already kind of built in, right?
They were born and GitHub was already there kind of thing.
So you don't have to push that far.
It's still mostly on the, maybe on the software design side of things.
You know, how you structure your software, how you tackle that particular problem, how you organize the code, how you optimize things for your particular architecture.
And so on.
Okay, cool.
And you're also working on this SKA construction, the Square Kilometer Array.
Yes, yes.
That's a whole topic.
I guess we'll talk more about it later.
But we are one of the main institutions that are working on the Square Kilometer Array project.
Yeah, so it's interesting.
I don't know if this works for light, but it does for radio, that if you put multiple detectors and sort of densely, but not actually connected to one giant antenna or something, you can put that together like a bigger detector, right?
A bigger lens in the radio world.
So that's the idea, right?
Yes, and that's exactly the idea.
It's called interferometry.
You basically, if you have, say, three antennas, A, B, and C, what you do is you take measurements individually from A, from B, and C, and then you correlate every other pair.
So you correlate the signals from A and B, from B and C, and from A and C, and you do that with a correlator, which is the one that is doing all this mixing of signals, and out goes one correlated signal, which is as if you have one big antenna.
So that's what happens in radios for me.
I think, I'm not sure, but I think in optical you can also do interferometry, but I'm not sure how the mechanism works in that sense.
Cool. So this SKA project, this is the Square Kilometer Array, which is an international project that you all are working on involving 13 countries that are, I guess, full members of the project and four others who are just participating, right?
Yeah, that's right.
The Square Kilometer part is the collecting area because we're starting to run out of adjectives.
There's things like the Very Large Array, there's the Extremely Large Telescope.
Where do we go?
Yes, exactly.
It actually tells you what the collecting area of the final system is going to be.
Now, we're going to be building this thing in two phases.
Phase one will only be 10% of the final telescope, which means, I mean, it's being built in two countries.
So the low-frequency component is coming to Australia, to Western Australia, and the mid-frequency is going into the Karoo in South Africa.
So there'll be 196, 15-meter dishes in South Africa and 131,072 antennas in Western Australia.
There's a fair bit of kit going out with a collectif of 650 million euros.
650 million euros.
Just for the first one.
This is the first part, yeah.
I don't know.
131,000 antennas bringing in all this data.
Yeah, that is a huge amount of antennas.
And it's spread over a square kilometer.
Well, it's a huge amount of data.
Yeah.
It's about 550 gigabytes a second.
550 gigabytes a second.
I don't really have a great way to understand that number, honestly.
Like, you've got to think of, like, large cloud services, like YouTube or Netflix or something like that, right?
Yeah.
Just about 16,000 hours of standard definition YouTube every second.
Wow.
Yeah, or you can visualize it if you take your, you know, your hard drive, your 500 gigabyte hard drive, and you throw it, and you throw one of those every second, right?
That's basically it.
Yeah.
That's a lot of data.
Also, it takes a lot of power, right?
Yeah.
And that's one of the key things, because we would like to be as green as possible, but we've got a power cap on us at the moment of 5 megawatt.
Biggest, most powerful system on the planet at the moment is 13 megawatts.
So that's still a challenge we have to address.
Yeah.
You almost need your own power plant to power.
Oh, well, we've got up at the Murchison Radio Observatory, the CSIRO, who've got a couple of megawatts of solar up there already.
Yeah.
Okay.
Is it the blades that generate RFI, or is it the generators that generate the RFI?
It's the generators.
Yeah.
This portion of Talk Python to Me is brought to you by Linode.
Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale that you need to take your project to the next level.
With 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise-grade hardware, S3-compatible storage, and the next-generation network, Linode delivers the performance that you expect at a price that you don't.
Get started on Linode today with a $20 credit, and you get access to native SSD storage, a 40-gigabit network, industry-leading processors, their revamped cloud manager, cloud.linode.com, root access to your server, along with their newest API, and a Python CLI.
Just visit talkpython.com.com.com.
I think if I could just throw those out there really quick, if you guys could just comment on them.
All right.
One thing, these are facts about the final system.
So this is where we will get to when we finish building it.
Right.
Okay.
So, yeah, you're only talking, we're only really working on stage one now, and there's going to be some beyond that, right?
Oh, yeah.
Yeah.
Awesome.
So the next one, the next amazing fact is that the SKA central computer will have the processing power of 100 million PCs.
Rodrigo, is that because there's a bunch of GPUs, or are there like really just a lot of CPUs in there?
It's both.
So the final design of the computer for the SKA is still not fully decided, but it's definitely going to be a mixture of both.
Right.
And, yeah, so all of this is based on the, we calculate how many computations we will need to do.
Therefore, that kind of gives you the size.
Wow.
Okay.
The next one is the dishes will produce 10 times as much data traffic as the global internet.
Yes.
That's crazy.
Yeah, yeah.
That's because you have so many dishes, right?
Right.
This is before it goes to the correlator, of course.
Like what comes off the correlator, as Kevin was saying, is about half a terabyte per second, which is obviously not what the global internet traffic is.
But what comes out of the individual antennas, yeah, it definitely is bigger than the internet traffic.
Wow.
And there's a bunch of fiber optic that brings it back to these correlators that then like process it and averaging.
Yeah, exactly.
Yeah, yeah.
Yeah, crazy.
And then I guess finally the aperture arrays could produce up to 100 times the global internet traffic.
So, yeah, there's, I think this is a pretty interesting one.
Honestly, the one that's most exciting to me is the one about the airport radar on a planet tens of light years away.
That's what everyone is waiting for.
There are only two planets that we know of at the moment that fit within that area that could potentially hold life, though.
So, I mean, our nearest neighbor's alpha centauri, a proximus inside, has got two planets around it.
But it's a red dwarf, which means that it's a red dwarf, which means that it's a red dwarf, which means that they're quite thirsty with lots of solar flares.
So life as we know it would probably struggle to evolve there.
You want a nice star like ours that's nice and sensible and not throw a huge amount of rubbish at us.
Yeah, do you want to get like a cleansing radiation spray every 10 years or whatever?
Yeah, that's right.
It's not good for you.
Yeah, there's probably not enough sunscreen to like help you with that one.
I don't know.
Yeah, that's one of the sad things for me about all of this space stuff.
I really wish.
It's just so big that it's just really challenging to actually explore it, interact with it, measure it.
Like even if you do get measurements back, it's like, well, that was 100 years ago.
It would take another 100 years to like send him a message.
We've only got away four years.
I mean, last year, year before, I took a bunch of primary school students.
We taught the European Space Agency into lending us their dish at New North here.
And we sent messages to Potsdam Center.
All right, so wait 4.2 years or 4.2 years for it to get there for them to decide for it and send a reply back.
So in about six years' time, we'll know.
Yeah, that's not too bad, actually.
Not too bad.
Cool.
So I guess maybe the next thing that's interesting to dig into before we get like fully into the programming side of things is just like what kind of questions are you guys trying to answer?
I mean, it's super cool to have this giant radio telescope with 131,000 antennas together in this giant array.
But you get some measurements off of it.
Then what?
Well, one of the things that we've been joking about, but it's the cradle of life.
Are we alone?
One of the things a radio telescope can see is molecules in space.
We have water, hydrogen sulfide, ammonia, carbon monoxide.
But we can also see things like methanol, glycolyl nitrate, which is a simple sugar, and amino acetyl nitrile.
Now, if the clarionite, and you look up at the night sky, look at the constellation Orion, there's a nebula in there that has these chemicals floating in the planetary nebula.
And that's precursor organic compounds to what basically we are.
Yeah.
Yeah, that's super cool.
And if those gases and small particles coalesce into planets, those planets are going to have those things.
Or asteroids that crash into planets, right?
Yeah.
I mean, the other thing we have to look for is things like galaxy evolution, testing cosmological models, looking for dark matter, dark energy, origins and evolutions of cosmic magnetism.
We really don't know much about that at the moment.
And one of the fun things is, in the epoch of re-ionization, I'll put my teeth back in, the epoch of re-ionization.
After the Big Bang, we had everything being highly ionized gas.
And then, about 300,000 years, it became neutral and dark.
And then, slowly, as galaxies and quasars began to re-ionize things, stars started to appear, galaxies started to appear until about a billion years ago, when everything started to become transparent again.
So, we want to go back and have a look at that time.
And to do that, we need a huge collecting area, because radio photons are about 2 million times weaker than optical photons.
Right. So, you've got to have something incredibly sensitive to go far enough back in time to see that kind of stuff, right?
Yeah.
These measurements that allow you to see things like hydrogen and water and carbon monoxide and so on, each molecule has its own signature in the radio wave.
Yeah.
I mean, it's in the spectra.
So, we can look at the spectra and see, you know, there's a peak there.
There's a line there.
Well, that probably means it's being absorbed by something.
This is something admitting.
Right.
So, you know, it's just spectroscopy, which is used in optical, x-ray, ultraviolet, infrared, radio.
We all do it.
Okay.
Yeah.
So, it's like NMR, far away.
Yeah.
And then, of course, you know, we look at the redshift to see how far away things are, because, you know, space time expanded, the radio waves stretched.
Yeah.
I guess you've got to compensate as well.
We can then look for it and see how far away things are.
Wow.
It's really amazing that you can just send out radio waves and then get all this information.
Oh, no, we're not sending.
We're receiving.
Yeah.
Yes.
Okay.
Thank you.
But it's like that you can measure these radio waves.
Hmm.
And just, you can basically see it, right?
It's almost like as if you've got an optical telescope, but, you know, you're computing a visual representation for humans, right?
Yeah.
Except for it takes a lot longer.
Speaking of all the computation stuff, let's dig into it.
So, I know, Rodrigo, you're working a lot on this project.
And so, you guys have got your hands on this pretty serious computer, right?
Yes.
So, the work that we did last year was about running simulations of all of this, but not only, you know, one or two computers, but at very big scales.
Basically, to the biggest scale possible that we could achieve now and trying to come up with what the system will look like in 10 years when we actually have to run it at that scale, right?
So, we teamed up with the Oak Ridge National Labs in the US.
And they own, at the moment, the biggest, not the biggest, the fastest supercomputer in the world.
It's called Summit.
So, Summit has over 4,600 nodes.
And on each node, you find six GPUs, six V100 NVIDIA cards, plus something like 160 cores.
It's like each node on itself is a beast.
And you have 4,600 of them, right?
Right.
We teamed up with Oak Ridge.
We wanted to run a simulation on their computer.
But, of course, they also wanted something kind of back, right?
It wasn't a free launch.
And we have been collaborating with them for a number of years.
And one area of collaboration that we have been working on is using their ADOS2 library.
I can dig into that in a second, but it's basically an IO framework for largely distributed programs using MPI.
So, that was the deal.
We got some time in Summit.
We have an ex-PhD student of ours who is working right now over there.
So, he was our main contact point.
His name is Jason1.
Yeah, we decided to run a couple of different experiments to test all these individual parts.
So, the first experiment was to simulate an actual observation of an SKA-like telescope.
And that was basically using the whole machine.
We used almost all the nodes and all the GPUs in all of these nodes to simulate what the correlator would produce when observing, right?
So, we're not simulating individual antennas.
Right.
We're just simulating the output of the correlator, right?
The observation that we decided to simulate is exactly the epoch of ray ionization, which is one of these big use cases of the SKA.
So, we decided to simulate that.
We simulated the output of correlator as if it was correlating as many antennas as the SKA.
The only aspect that we had to tune down a little bit is the number of frequency channels that we, double quotes, observe in our simulation.
In the SKA, you can observe up to 64,000 channels.
We simulated about 28,000, 29,000.
Basically, one channel per GPU.
Yeah.
So, you had 27,000 GPUs running.
Yes.
Yeah, that's right.
Full power for six hours to generate a portion.
No, sorry.
For three hours, simulating six hours of observation.
Exactly.
Yeah.
Yeah, yeah, yeah.
To generate all this data.
Talk about the computing, right?
It goes in and this data just comes screaming into this supercomputer and you have to distribute it out and basically do all this processing.
Is it like image processing or is it like time series processing?
What are you doing?
In this first experiment, first of all, we generate the data in the supercomputer, right?
So, we don't have to bring anything from any external source.
We just generate the data on the GPUs and then we stream it out of the GPUs into the CPUs on each individual node.
We did some data reduction.
We basically took data from different channels and averaged it together.
So, we did that at the local node level first.
You know, the six GPUs, we coalesced into a single output signal.
And then every six nodes, we did again another further reduction.
This is something that would be similar to what you would be doing at the SKA.
And that basically reduces the amount.
There are, I guess, scientific reasons of when and when you don't want to do this kind of averaging.
But for the epoch of rayonization, it's certainly something that you would do.
So, we did this two-step averaging and then we brought the data immediately to disk.
And that was the first experiment.
It ran on its own.
There was no further computation on that first experiment.
Yeah.
So, one of the things that's interesting is you guys are getting so much data that you can't write the raw data to disk.
Yeah.
So, you've kind of got to process it and filter it down and do this averaging.
And then you can finally save that bit, which is probably still a lot of data.
Yeah.
So, for example, the data that we generated of the GPUs during those three hours was about 2.6 petabytes.
And what we ended up on this was about 110 terabytes.
Wow.
So, yeah.
And that's in three hours.
Yeah.
That's in three hours.
Yeah.
That's in three hours.
As I was saying, we decided to average on this particular case, but on the real thing.
And you may actually need to write all that data into disk.
And that's why we did some other experiments in that direction.
So, when I think of what I'm visualizing is there's just like you're saving so much data.
You know, if you have a power plant that runs on coal, there's like every day a giant train that brings in coal and it just is continuously going.
I can almost imagine like you almost are just like constantly shipping in hard drives and plugging them in.
Like, how do you deal with that?
The truck of hard drives is here today.
Quick, plug it in.
It's getting full.
Well, in the SKA, there will be a double buffer, basically.
So, as you observe, you fill one of your buffers with all the incoming data.
Once your observation finishes, you swap the buffers.
The next observation can fill the other buffer while you process the first.
During this later processing, again, reduce the amount of data by, again, orders of magnitude.
And that's what this.
So, I was talking before about the first experiment.
Well, we did a second and a third.
In the second experiment, we took the output of the first.
And we effectively reduced it even further.
So, the output of the first, which is basically this reduction of data from the correlator, gives you what we call in radio astronomy, visibilities.
So, in radio astronomy, you don't observe pixels and images directly.
You observe these visibilities that later on you have to actually image.
You have to create an image from them.
And that takes much longer, as Kevin was saying.
It's a much complicated process.
So, that's why you can do it a bit offline.
And we did that during the second experiment.
We took all the 110 terabytes of visibilities and we created images for each of the channels.
So, if you have many images for each of the channels, you end up with an image cube.
That's how they're called in the real astronomy.
Or if you want, you can play it as a movie as you go across the different channels.
And that image cube, it turned out to be like 3.3 gigabytes or something.
Like, again, a massive reduction of data.
Yeah, that starts to get to the level you can write that down.
Yeah, yeah, yeah, exactly.
But it's no problem, yeah.
Yeah, exactly.
And that you can also distribute across the world more easily through the internet.
And again, in the SKA, there will be something like that.
There will be the main computer that will do the main reductions.
And after the main reductions are done, data is sent over to what are called the SKA regional centers.
And that's where the final science will be done.
Yeah, so it sounds a little bit like the Large Hadron Collider, which does a ton of computation and filtering and averaging and whatnot of the data.
But then it streams a bunch out to probably places like Oak Ridge and other places where it gets further processed and further processed.
It sounds like you might be doing something similar here in the end.
Yeah, yeah, exactly.
It's not about kind of reducing the amount of the size of the data, depending on your science use case, and then distributing that.
So, let me ask you guys something.
You're running the simulation on Summit in Oak Ridge, which is the fastest supercomputer in the world, or nearly so.
What are you going to do in the real one?
Like, are you going to build one of the largest supercomputers in Australia and then another one in South Africa?
Is that pretty much what you have to do?
Yes, I know.
So, by the time, it won't be the fastest, right?
Sure.
Compared to current standards.
We'll do it on our iPhones by then.
I mean, what is it?
Yeah, exactly.
Everyone will collaborate a little bit.
No, what's the plan for dealing with this?
Because it sounds like you've got to move a serious bit of compute next to this system.
Yeah.
So, the plan is effectively run something in the order, if I'm not mistaken, of 100 perapholops.
I think 150 perapholops is the size of the supercomputer that should be built, which is kind of comparable to what Summit is doing now.
When is the time frame for this?
About 10 years, give or take.
This portion of Talk Python to Me is sponsored by Clubhouse.
Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings teams together to ship value, not features.
Great teams choose Clubhouse because they get flexible workflows where they can easily customize workflow state for teams or projects of any size.
Advanced filtering, quickly filtering by project or team to see how everything is progressing.
And effective sprint planning, setting their weekly priorities with iterations and then letting Clubhouse run the schedule.
All of the core features are completely free for teams with up to 10 users.
And as Talk Python listeners, you'll get two free months on any paid plan with unlimited users and access to the premium features.
So get started today.
Just click the Clubhouse link in your podcast player show notes or on the episode page.
It'd be fun to dig into some of the Python code and some of the architecture that you guys had to put in place to make this happen, right?
So a lot of these types of systems, they have a lot of C++ in place.
They also have a lot of interesting Python going on, I'm sure, in the data science visualization side, but also maybe more in the core of the system.
Yeah.
First, I should probably mention the execution framework that we use for this.
So instead of running things with MPI, we have been using an execution framework that we developed at ICRA, our institute.
It's called the Liujia.
Kind of difficult to pronounce, even more difficult to write.
But I will give you a link to that.
Yeah, super.
The view of this execution framework is a bit like Dask, which people are more familiar with, in the sense that you build a graph with your computations, and then you execute that graph in a number of workers, right?
Now, the big difference between Dask and the Liujia, our execution framework, is that Dask is very dynamic in its nature.
You can bring workers up and down, and then the scheduler will dynamically adjust the load to what you have available, right?
Whereas the Liujia is more designed for the SKA case in particular, but it's still pre-generic.
But one of the main design decisions was to work with a static deployment.
So instead of trying to be dynamic in nature and try to move data from here to there and restart the computation here and whatever, we try to be very static.
Because moving data from one place to another is a very expensive operation.
If the compute is what's expensive and the data is not that bad, moving it around to balance the compute and getting that to happen is really important.
But when you have so much data that it's more than the internet.
Yeah.
You don't want to be moving around the internet data.
You're already at probably near a limit of moving it around just to get it somewhere.
So, like, you know, combinatorially passing it around is not really what you're after.
Exactly.
Yeah.
So instead of focusing on that dynamism that that gives you, we focus on having very good schedule up front of your computations.
So you know exactly how long each one is going to take.
You know exactly how much data is going to be where.
And you keep it like that, basically.
That sounds very cool.
That's the main difference.
And we have been developing this in a prototype fashion, but now using it in real life world as well.
We used it for this summit demonstration.
So all the things that we run, all this big simulation, all the processes that we have to spawn and so on, all these 4,600 nodes, we did it using our execution framework.
And just to give a very quick overlook, the execution framework is using 0MQ to send messages between the different entities.
And they're called managers and node managers.
So we send events across the different node managers and we use 0RPC, which is an RPC framework built on top of 0MQ.
We use that to also do a couple of remote calls between different node managers.
All the scheduling of the graph is done using Python.
There is some interfacing with the Metis library, which is written in C, but there is a Python wrapper for that already.
Right.
But the rest is all Python.
0MQ looks really interesting.
And I haven't done anything with it, but it has a nice Python library.
Yeah.
It's very, very nice.
By ZMQ, right?
Yes.
Yeah.
That's right.
Yeah.
It seems like something that would be really useful if you're sending a lot of messages around and whatnot.
And then something I had not even heard of, which you had brought up, is 0RPC, which, so it basically sends messages out over 0MQ and then waits for a response or something like that, kind of to come back as another message?
Yeah, exactly.
Is that how?
Okay.
It's what you would expect from an RPC framework, right?
You can get a reference on a remote object and invoke methods and get replies, pass down parameters and so on.
And all of that then travels through 0MQ.
I think it's using message pack for the serialization and then 0MQ for the actual networking.
And on top of that, I think 0RPC has findings for different languages.
So you can also do inter-language RPC with 0RPC.
Right.
Okay.
Well, that looks really interesting.
And to me, one of the big challenges it sounds like of programming this system is it's just so big and so distributed that you really need these layers.
You know, you talk to this sort of, okay, I'm going to talk to the 0RPC.
It talks to 0MQ, which then might talk to this distributed scheduling service that then figures out how stuff actually runs, right?
Like there's just layer after layer.
Is that a big challenge?
Definitely.
Yeah.
You have to try to keep, as you were saying, all your layers as clean as possible.
Before we even settled on 0RPC, we also tried other RPC frameworks like Pyro4 and the remember which else.
So on top of, you know, having to build layer on top of layer, we also have to support different ones at the same time.
I think we still have the support there and you can kind of turn it on, but it's not really what we use.
We just use 0RPC.
Yeah, sure.
Another interesting library that you guys have and you actually maintain is iJSON.
Yes.
We use and maintain iJSON as CRC32C.
So iJSON, briefly described, is a way to iterate over very long JSON streams of data without having a big memory consumption.
So you parse, parse, parse the JSON iteratively and you get kind of parsing events out of that.
Well, there are different parsing levels.
You can have like full objects and you can kind of query and what kind of objects do you want to get from your JSON stream and so on.
And all of that is on iteratively.
So you get like an iterator, you know, we are preparing version 3.0 and in that one you will get asynchronous iterables as well if you are in the asyncIO world.
And we got into this because we were, again, dealing with very big computational graphs, which we express as JSON content.
That's how we transmit this from one site to another.
Yeah.
And the last thing you want to do is like load gigabytes of JSON and deserialize it.
Yeah, yeah, exactly.
I just want these sub items here and then the rest of the time I don't care about.
Or maybe I just want the first one.
Like a first would be fine.
Even if there's 10 million, just give me the first.
Yeah, yeah, exactly.
Yeah, JSON is super cool.
And I think people, there's probably a lot of people who could take that and use it.
You know, I was just, I had someone in the office hours for my online courses saying,
I'm working with something that's a huge amount of data, something like Google BigQuery or something like that.
It was like, it's too hard to load up all of this at once.
So I got to take little bits and load it.
And like, well, you know, have you thought about IJSON, right?
That'd be really cool.
And use a process like that or something along those lines.
Yeah.
You know, the other thing I kind of touched on it just a minute ago, but maybe you could speak a little bit more to it, you guys.
Something that just amazes me in general, but this is such a big scale of it that I think it's even
more interesting is a lot of times how we develop code in the small and then deploy it to somewhere in the cloud in a much, much bigger,
more complex system than maybe we're used to working on.
So, you know, the example that comes to mind for me is like, there's some developer at a coffee shop.
They're working on, you know, a MacBook Air or something completely weak like that, right?
And they're running a single instance of like a dev server.
And then they push something to GitHub.
It automatically gets picked up by CICD.
It pushed over and it kicks off, you know, like a whole new version of some giant app running in a Kubernetes cluster across,
who knows, 10 servers and a bunch of nodes and pods and so on.
And then it's like, I'm going to be able to do this thing.
And then like, it's scaled out to this huge system for you guys.
Like, how does that work?
Right.
How do you debug this thing?
How do you reason about like, it's little algorithms that are running.
Can you set a break?
Anything, right?
Is that like a thing that you can do?
Or is that like just literally too much?
It's just, it's impossible.
Can you, do you have like a Kubernetes cluster locally that allows you to kind of simulate this?
Or do you have to program on the giant thing?
No, you don't need to program on the giant thing.
So for all these summit experiments, we started, as you were saying, like on the small, on our own laptop computers.
I, and also different platforms.
I usually run a Linux machine, but some, some people in our team or most people in our team use Macs.
Yeah, we started on the very small.
And for that, you have to make sure that on the very small scale, you know exactly what's going on.
And you know that everything is working as you expect, so you don't have unexpected errors, unexpected troubles in the future, right?
Right.
For example, when, when developing Deluge, we have a very good test coverage for all the code base.
And we run all the tests, you know, without internet connection on a single node.
Because at that scale, you have to make sure that it's working, that everything is working fine.
And from then on, you start kind of escalating and testing more complex things.
But you have to have a very solid foundation.
That's true for, for the development of Deluge, but also for the development of the code that we use in the Summit demonstration.
Besides, again, on our laptops, then we went into, you know, a server that had one GPU, then a small cluster with two, three nodes that had a couple of GPUs on each.
The Summit system in Oak Ridge, it's a Power 9 system.
It's not an Intel system.
Again, we, before jumping into Summit, we jumped into a cloud provider in the US that offers Power 9 machines.
We made sure that everything worked there in a single node.
Little by little, you start tackling problems as they come before hitting the full machine.
Yeah.
And I guess for you guys, there's another level of challenging where the machine itself, you can't just go to it.
It's not like I could go to the cloud now and ask for a Kubernetes cluster if I'm willing to pay for a little bit of it.
And I could just do that whenever I want.
But I suspect this large computer is pretty much booked out.
And you can't just get it whenever you want to make it go full power, right?
Yeah.
Well, first of all, there are all the kind of the paperwork involved, you know, in getting permission and so on.
They have to send you a physical key.
So they sent me a physical key from the US into Australia that I have to use when I log into the computer.
So, yeah, it's not your everyday AWS systems, right?
Yeah.
And once there, all the systems work with queues.
So you submit your jobs into a queue.
And then the queue schedule decides what runs when.
So, yeah, you're competing with a lot of people.
Depending on how many resources you're asking, you will be delayed or not and so on.
Yeah.
But in Summit itself, we also started scaling little by little.
We started with experiments with 6 no's, 10 no's, 60 no's.
And little by little, we, again, started finding more and more problems.
You know, things that you never really think about.
Or very, very transient errors that only happen when you are spawning, you know, tens of thousands of processes.
And one of them fails.
And you didn't see it before because you didn't spawn as many processes before.
Yeah, those are tricky to catch.
Yeah, yeah.
You're not in control at that point, right?
Your control was it's like up and running.
Everything's fine.
Now your code runs, right?
Yeah.
And it's only once you find those errors that you can start to reason about them.
And that's also very difficult, right?
You cannot just go and attach yourself to thousands of processes at the same time and kind of step the back through them.
You have to set a break point on Summit.
Yeah, you will have to log a lot of stuff and then reason very heavily about what could be the possible cost.
So we caught a lot of those.
And then the final bit was the stress on the file system.
So all of these clusters, they usually have a central file system that is shared across the cluster.
But obviously, as you use more nodes, you are putting more stress into the central file system when reading and writing data, right?
So that becomes a problem.
Yeah.
So what was it like when you basically hit enter to submit the job for the 27,000 GPUs?
Were you like, we better get it right.
Yeah, we all assembled into a room.
We did a countdown and we hit enter.
Yeah.
We basically had one shot doing the full simulation because we were given a time allocation of 20,000 node hours.
We knew that in the big experiment, we were going to be using about 15,000.
So it was either going to work or not, right?
But it did.
It did?
So all the gradual scaling up, all the testing, it all worked.
It paid off.
Yeah.
Did you get like a weird news report in Tennessee that it was suddenly hotter a little bit that day than they expected?
I wouldn't be surprised.
Like there's a warm breeze coming from the east.
I don't know what that is.
But yeah, that thing must have been really screaming.
That's quite something.
All right.
So I guess we could probably wrap it up in terms of time.
But this is super interesting.
So maybe you guys could just tell us maybe some of the lessons learned.
We kind of touched on them a little bit, right?
This like scale it up a bit at a time.
But what are some of the lessons you all learned?
Yeah.
For me, it was, I think it was the full process mostly.
I also maybe learned a bit about Summit in particular.
But it was more the process of scaling all this exercise up.
That was really challenging.
It really stressed the importance of having very solid foundations before you take the next step.
Because otherwise, if you are kind of giving steps in the dark, you will continue hitting walls.
Sure.
Kevin, how about you?
I'll reiterate what Rariko said.
I mean, a lot of the early work with Deloji, obviously, is Test Monkey.
There's a big project called Chili's, which is a very deep observation using the telescope in Socorro.
So four years.
And we did all of that on the Amazon cloud.
And slowly build it up using a different software stack slightly.
We didn't have all the problems with the GPUs.
But we would start with two or three nodes, parallelize it.
Does this work?
Are we getting what we want?
And then slowly wind it up.
So, I mean, it doesn't sound much now when we compare it to Summit.
I used to run it about 200 down by four nodes.
Okay.
Very cool.
Now, I guess let's wrap it up with the final two questions for you guys.
And you're welcome to throw out some of your own that you're maintaining or pick a different one.
But how about, yeah, notable PyPI package?
We'll start with that one.
Notify.
All right.
Awesome.
Yeah.
I'm sure that's a foundation of a huge amount of work that you all are doing.
Yeah.
I think I will do some more stressing on iJSON just because I maintain it.
And because there is this new version coming.
So, yeah.
Go out.
Try it.
It's pretty cool.
Yeah.
It looks really, really useful whenever you have a ton of, like, very large JSON or you need to not load it into memory.
One I picked up from your other podcast is Typer.
That's beautiful for writing command line interfaces.
Oh, yeah.
Typer is great.
I think we covered that on Python Bytes.
That's right.
Yeah.
That's right.
So, Cracker.
Thank you for that one.
Yeah.
You're welcome.
That's super.
All right.
Now, when you all are writing some Python code or really any code,
what editor are you using?
PyCharm.
All right.
I use Eclipsed.
I've been using Eclipsed for the last, like, 15 years for writing Java, C++, Python.
So, Eclipsed in Python comes with PyDev, which is the...
All right.
You get PyDev and that adds it in, right?
Yeah.
But on the other way around, I used IntelliJ prior to going to ICRA.
So, I just...
You know, it has a nice look and feel.
Yeah, it does.
Yeah.
It's a pretty easy transition from IntelliJ over to PyCharm.
All right, you guys.
That's probably a good place to leave it or get short on time.
But thank you for sharing.
This is super interesting.
Final call to action.
People want to learn more about the SKA.
They want to learn about some of these libraries you're working on, more about radio astronomy.
What do you tell them?
There is also a lot of material out there, too.
If you're interested in the topic, there's tons of material.
Just go to the SKA telescope organization website, to the ICRA website.
I'm sure in YouTube, it will be full of videos as well to learn about all these different concepts.
Cool.
All right.
Well, thank you both for being here.
This was a lot of fun.
And I really enjoyed learning about radio telescopes.
And I didn't even realize, Rodrigo, that you are the maintainer of iJSON,
which is a nice little bonus.
Very cool.
Yeah.
Well, I took over just last year, I believe.
So I'm not the original creator.
I just became the maintainer after I started kind of contributing more to it.
Super.
Well, thank you, Rodrigo.
Thank you, Kevin.
Have a great day.
Yeah, you too.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode have been Rodrigo Tabar and Kevin Vinson.
And it's been brought to you by Linode and Clubhouse.
Start your next Python project on Linode's state-of-the-art cloud service.
Just visit talkpython.fm/Linode, L-I-N-O-D-E.
You'll automatically get a $20 credit when you create a new account.
Clubhouse is a fast and enjoyable project management platform that breaks down silos
and brings teams together to ship value, not features.
Fall in love with project planning.
Visit talkpython.fm/Clubhouse.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
everything bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.