Python's place in climate research is an important one. In this episode, you'll meet
Joe Heyman and Ryan Abernathy, two researchers using powerful cloud computing systems and Python
to understand how the world around us is changing. They are both involved in the Pangeo project,
which brings a great set of tools for scaling complex compute in the cloud with Python.
This is Talk Python to Me, episode 361, recorded April 1st, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes
at talkpython.fm and follow the show on Twitter via at talkpython. We've started streaming most
of our episodes live on YouTube. Subscribe to our YouTube channel over at talkpython.fm
slash YouTube to get notified about upcoming shows and be part of that episode. This episode is
sponsored by SignalWire and Sentry. Transcripts for this and all of our episodes are brought to you by
Assembly AI. Do you need a great automatic speech-to-text API? Get human-level accuracy in just a few lines
of code. Visit talkpython.fm/assemblyAI. Joe, Ryan, welcome to Talk Python to Me.
So much for having us. Hey, it's great to be here. It's fantastic to have you here. I'm really excited
to talk about earth science and all the cool large-scale computing stuff and cloud computing and
things like that with you. It'll be a lot of fun. So really looking forward to getting into that. Now,
before we dive into the topics, let's just start with your story. Joe, I guess you go first. How'd you
get into programming in Python? My path came through grad school. I was studying civil engineering and
climate modeling as a graduate student at the University of Washington. I was in a computational
hydrology group. So we were doing lots of computer things. And my PhD advisor at the time was like,
we want to do Python stuff. I don't know anything about it, or I don't know much about it. You should
be the kind of the guinea pig student to bring our group into the modern era. So it kind of threw me to
the wolves. And I ended up really kind of taking on a role that not just learned it, but then started
teaching other people and I ended up contributing to open source packages and the rest is history.
Oh, that's fantastic. What were you using before? You said you brought them into the modern era. Where were you
coming from? What was the dark ages?
Some terrible mix of like Perl and Seashell and C and Fortran and a bunch of other shell scripting
languages. So it was a total spaghetti land.
Wow. That is a spaghetti land. I would say Python and Jupyter and the PyStack probably sounds a little
simpler. Yeah. The connections are a little more natural for sure.
Indeed. How did people receive it?
It's been great. I think for me personally, it was like quite revolution in what was possible,
but then passing it around the lab and then around kind of the research community since then,
it's been overwhelmingly positively received and we're doing totally different things than we could
have done without it. And I think that's the big change. It's not just that it's like a little easier
to program, but that you can do things that you couldn't have done before.
Interesting. Yeah. Were people worried that, you know, coming from C and Fortran that Python wasn't
fast enough? They're like, we can't use this. This is one of these slow scripting languages.
Or was it, you'd already proven and it was fine.
No, I think, I mean, you hear that on occasion, but I think the developer velocity
outweighs that in 99% of the cases.
Yeah, I agree.
You can always optimize the 1% case further.
For sure. Ryan, how about you? How'd you get into programming in Python?
Kind of been a lifelong programmer. So I was actually just thinking back when you asked that,
I think I wrote my first basic code at age seven. My dad worked for IBM. And so I'm like,
really been like a kind of lifelong computer nerd. Drifted away from that a little bit in college,
where I majored in physics. But then, you know, in graduate school, I did a PhD in climate physics
and chemistry at MIT. And, you know, I had a huge need for scientific computing in that. So all of a sudden,
sort of my computer, you know, stuff started really coming back full and center of my world.
It was a MATLAB shop, you know, MATLAB Fortran was the stack, you know, there.
After I sort of did my first project around 2006, 2007 in MATLAB, I decided, you know,
I just, I'd been doing open source hackery for in other languages for many years. And I was like,
I got it. I need an open source scientific computing solution. So I tried Python, got into Python around
2008. So that was when like, I've been at it long enough to have like compiled NumPy.
Yeah, that's like really when NumPy was basically coming out is right around that time.
Yeah.
Or Anaconda and the other one, you know, then just rolled with it ever since. And I,
so I was like the early adopter Python guy around there. I like helped get a lot of other people
into it, but it was still always just in my own projects, right? Like there was no community.
I really got into open source community development probably around 2014, 2015,
when I discovered X-Array. That is like the project that really like turned me from just
a user to a contributor.
Fantastic. Yeah. That's like multi-dimensional NumPy goodness, right? Yeah. We'll dig into it.
Yeah. Was that other distribution to Anaconda? Was that Canopy? I see out in the audience. Thank you,
Erie. Cool. The other one I was thinking of was ActiveState. So yeah, there's these,
these different distributions people can get for optimizing for different stuff. It's great.
Ryan, what are you doing day to day? It sounds like you both are still doing research university-like
things. Absolutely. So I'm a professor here at Columbia University in Lamont-Darody Earth
Observatory. And I sort of manage a medium-sized scientific research lab and teach at the university.
But then I like wear this total other hat as like open source developer and contributor.
That can be sometimes a little exhausting to try and wear both those hats at the same time.
But I really enjoy it. Our work in our lab is focused on computational oceanography,
trying to understand the role the ocean plays in the climate system, particularly the role that small
scale ocean processes, eddies, fronts, instabilities that are occurring at the say 10 to 100 kilometer
scale, how that sort of turbulence and variability influences a large scale ocean and the role it plays
in our changing climate. Right.
So the way we do that research is by working with large scale satellite data from NASA. So I'm involved
in the NASA surface water and ocean topography science team, a new satellite mission that's launching
this year. I do a ton of numerical modeling, simulating the ocean with computers. At the end of the day,
we're doing data analysis. Some of which was just sort of traditional statistics and visualization.
increasingly machine learning, AI, ML are part of our toolkit that we use to try and understand the ocean.
But the bottom line is, yeah, just working with a lot of data every day, diverse projects,
that has really forced me to center the rule of these tools in our work and recognize them as sort of
that is our, like a lot of my colleagues, you know, in other buildings at our lab, like they'll have
like a million dollar mass spectrometer. You know, they have like an instrument they use to do science.
Some crazy laser or something. Right. And they like turn the crate and like, we just,
we're like a data driven lab. And so I think a Pangino in a way is our instrument that we all
contribute to and maintain that then helps us to do all of the research projects that we want to pursue.
Yeah. How fascinating. You talked about running a research lab and then also doing this open source
thing, this dual hat thing. The world may has changed, but when I took a couple of computer science
classes at university, when I was my undergraduate degree, I didn't feel like a lot of the,
the instructors or professors there really had much real world experience in programming and stuff.
And I think things like this, like contributing to X-Array, it must give you this really grounded
sense of that. Not only these are the tools that you can use, but like, here's how it works. These are
the people doing it. Like you're in the trenches. Like, do you think that makes a big difference?
I think we have a major education problem around computational science. And I say this as someone,
like a university professor, like we have no curriculum to teach someone how to be like an
effective computational science. And particularly in the context of like open source community driven
software development, we have computer science classes that will teach you a lot of great things
about algorithms and data structures and even machine learning, but they won't teach you how to like
write effective software. And as you said, you have currently, we assume you have to learn that in
the trenches, just getting into a project. Maybe you work at a company for me, definitely. I upped my
software engineering team so much after I got involved in community open source, because there were people
like Stefan Hoyer, you know, you know, Google staff engineer who were like reviewing my PR.
Right. So that was huge. But I wish actually the university could teach this skill set because I
think it would help the world a lot. Yeah, I think it would as well. I think we can absolutely find space
in the curriculum for it. I think math might need to give up a little bit to allow for computational
math rather than symbolic math. If I could pick, I don't want to do realist too much. And I would do
want to let Joe get a chance to talk as well. But I think geometry and the going through proofs
and the thinking about how do I take axioms and using proofs to solve problems is exactly the same
mindset and the way of thinking as solving a computer program or solving a problem with a program.
And I haven't applied geometry that much, but I've sure applied a lot of computers. So anyway,
I just put that out there for people. You might be a little biased.
I may be a little biased, although I do have two math degrees for what it's worth,
but I'm still willing to put geometry out there. Anyway, Joe, how about you? What are you doing
these days? Yeah, so I wear a couple of hats as well. My main hat is I'm the technology director
at CarbonPlan, a nonprofit that's working on the climate problem. And our focus is really on
improving the transparency and the scientific integrity and quality of climate solutions.
We do that by building open source tools and open data and doing research into the various climate
solutions that are out there. So we use a lot of open source software to do that. And we build a lot
of open source tooling, including software to help tell stories about different climate solutions.
The other hat I wear, I'm a scientist at the National Center of Bramispheric Research,
where that part of my role looks a lot like Ryan's day to day. Yeah, we study different things, but
I work with big climate model data and do data analysis and all of that.
Yeah, sounds really fascinating. At CarbonPlan, what kind of data do you all use? Do you hook into electric grids?
Do you analyze the mixture of electric grids or transportation or what kind of problems and things
are you solving there? It's a bit of everything. We do big data, little data and everything in between.
But, you know, so like one of the areas we spend a lot of time working is in the area of forest offsets
and trying to ask questions about the quality and the potential of using forests as a climate solution.
And so there we're using everything from in situ observations where people go out and measure trees
with a tape measure. And they do that every five years. And that's like actually a fairly small data
set, even though there's a lot of trees out there. It's just there's only so many measurements you can make.
And then we also work with climate model data. We study climate risk to forests. And so there we're
building models of future forest fire risk and trying to understand how that's going to change in the
future. So that's like big data stuff. We're doing lots and lots of model building and machine learning
and that sort of thing on top of climate model data. Sounds fascinating. You and I are both in the
Pacific Northwest and last year was not too terrible for fire season, but recently we've had some pretty bad
forest fires up here and it's definitely concerning. So yeah, it definitely feels like I'm studying the
world around me more than ever when we're working on these fire problems and then also experiencing the
smoky weather that we've been having in the summers in the West Coast last few years.
Yeah, it's been pretty crazy. And I mean, I think that's a theme in climate science right now. It's gone
very quickly from this academic problem to something that so much of society and our economy is engaging with.
companies, you know, are just getting to work on adapting to climate change because they're feeling
it in their bottom line. And it's different than things were 10 years ago.
Well, that's good to hear. I'm both pessimistic and optimistic about how things could go. You know,
I, there are so many full discoveries. Folks like you are using, you know, Python and computation
to really understand exactly what's happening and keep your finger on the pulse of where they're going.
And then also I see, you know, a mom and her one small kid in a Chevy Suburban next to me,
you know, idling in traffic. And it's like, I don't know. People do have to internalize it,
I think a little bit more, but it's, I wonder if it is maybe in business, they're starting to see,
starting to react a little bit sooner. Right. I think companies feel pressure of economics sooner
than people do a lot of the times. I know. I think that's true. I think there's also
social pressures that are pushing companies to act soon. And so I, you know, it's not just it,
sometimes it's altruistic, but also I think there's marketing involved in a range of other.
Right. Just don't want to look like the bad company. Yeah.
If they can put on a good image and it's, it's worth it, but whatever gets them to do it,
I don't care if it's.
Yeah. That's what I was just going to say. We don't have to shame that. I think that
there's a lot of action that needs to happen in a lot of sectors right now. And so to the extent
we can motivate that through one mechanism or another, that sounds like a good idea.
Yeah.
This portion of Talk Python to Me is brought to you by SignalWire. Let's kick this off with a question.
Do you need to add multi-party video calls to your website or app? I'm talking about live video
conference rooms that host 500 active participants, run in the browser and work within your existing stack,
and even support 1080p without devouring the bandwidth and CPU on your users devices. SignalWire
offers the APIs, the SDKs and edge networks around the world for building the realest of real time
voice and video communication apps with less than 50 milliseconds of latency. Their core products use
WebSockets to deliver 300% lower latency than APIs built on rest, making them ideal for apps where every
millisecond of responsiveness makes a difference. Now you may wonder how they get 500 active participants in
a browser-based app. Most current approaches use a limited but more economical approach called SFU or
Selective Forwarding Units, which leaves the work of mixing and decoding all those video and audio
streams of every participant to each user's device. Browser-based apps built on SFU struggle to support
more than 20 interactive participants. So SignalWire mixes all the video and audio feeds on the server and
distributes a single unified stream back to every participant. So you can build things like live
streaming fitness studios where instructors demonstrate every move from multiple angles,
or even live shopping apps that highlight the charisma of the presenter and the charisma of the products
they're pitching at the same time. SignalWire comes from the team behind Free Switch, the open source
telecom infrastructure toolkit used by Amazon, Zoom, and tens of thousands of more to build mass-scale
telecom products. So sign up for your free account at talkpython.fm/signalwire and be sure to mention
Talk Python to me to receive an extra 5,000 video minutes. That's talkpython.fm/signalwire and mention
Talk Python to me for all those credits.
We're getting like maybe down this climate rabbit hole, but this is the probably the most important
issue of our time. So let's go down it. I mean, you got to distinguish between the terms we use are
mitigation versus adaptation, right? So mitigating climate is doing things like burning less fossil
fuels that are going to reduce the potential impacts of climate change. Adaptation is just accepting that
climate change is happening and it's going to happen and changing our behavior like infrastructure.
And so when I say to see a lot of companies taking action, I see especially a lot of companies taking
action from where I sit on adaptation using earth system data, using our projections from our climate
models to make business decisions under this changing climate. Mitigation is what we've been calling
for for decades. And that's where like the Chevy Suburban comes in. I guess I really push back against
the idea that like personal choices are like an important part of mitigation. This is, I think,
this narrative has actually been counterproductive. Like, don't think we need to rely on personal,
like ethical choices about like which type of like bags to bring to the grocery store. I mean,
like it's important, but like this is a very, very large scale.
It's solving the problem. I think very, very much on the edges when you're just going like,
but there's this huge middle part. What do we need?
Global scale regulation around carbon emissions in order to mitigate climate. And that's a political
problem.
It is. Well, the renewable energy story seems to be coming on faster than people thought recently. So
there is a lot of hope in that space. Now let's talk, you know, you both mentioned a little bit of
this sort of blend of like open source side of things, and then the science side of things. Let's just
talk for a moment about just some general best practices with open source and science and stuff
like that. One of the things I guess is Ryan, you talked about having people like these high-end
software engineers reviewing your code and stuff. And I suspect there's a lot of lessons you've learned
that you can kind of bring back to the science world from that open source experience.
I think there's this whole spectrum of open science, right? And open source activities,
right? So right now it's pretty common in scientific fields to encourage projects,
research projects to publish their research code under an open license or put it on GitHub or
something like that. And I see that it's just like a very, very first step towards a much more
transformative way we do science as a community. As you well know, like just putting a repo up on
GitHub has essentially no impact, right? Like if no one uses it, like if someone pushes their commit in a
forest and no one hears it land, like, okay, great. Like you checked a box. The real goal of open science
is to encourage more reuse, more collaboration, and accelerate the velocity of scientific discovery.
And that takes more than just putting your code out there. And of course, putting your code out there
is the first step, but it actually takes making sure people can run it. Like they have the environment for
it. Like they can access the data that it needs to run, that they understand what it can do, that it's
coded in a way that is extensible and modular. And all of those things are a lot more than a license.
They're about actually writing good scientific code. And so I do think that just the process of getting
involved in open source is a huge form of education for scientists about how collaboration can work,
not just even in code, but in general, the way the collaboration process works in a
well-functioning open source project is kind of miraculous.
Yeah, it absolutely is. And you know, there's a lot of barometers people use when they go and
look at an open source project to decide, can I trust this thing? The obvious ones are like,
how many stars and forks? Like, is it a popular thing that people seem to care about? But others are,
does it have tests or, you know, does it seem to be operated in a way that is going to lead to
contributors being able to contribute and, you know, the software evolving over time in a way that
that they could depend upon? Right?
Yeah. I think another thing here that's really important to think about is what the incentive
structures are for a researcher working on a scientific programming problem. And for, you know,
for most graduate students or researchers at institutions that Ryan and I work at, the goal
is to write a paper or to produce a dataset. And the software has been kind of thought of as like
a tool you use to get there, but it's not necessarily a tool that you fix up or improve along the way.
And I think one of the things that we've been trying to do is kind of break that pattern
a little bit and think of that, like the whole ecosystem of tools that we're working with is
improvable so that we don't have to reinvent the wheel. And individual researchers have,
I actually, and I just, maybe just speaking for myself, being able to say, okay, I'm going to take a,
rather than take the like shortcut path to get to my, the end of the paper, I'm going to like,
improve the ecosystem so that later on I can reuse this improvement, but also so Ryan and others in
the community can reuse it. And that's like a fundamentally different way of thinking about
the tools you're using.
That's interesting. It sure is. I've only spent a couple of years in that space, but my experience was
so much of the code, at least traditionally had been written just to solve a very focused problem and
not in a way that could be adapted to future problems, right? It'd be like, well, we're changing
the algorithm or we're, it's slightly different data. So we'll make a copy of this script and we'll
copy it over there. And we'll just like, you know, maybe there's not a single function in the whole
thing. It's just top to bottom. And I suspect adopting some of these techniques to sort of produce
more of a library out of it. Even if you put it on GitHub and nobody comes, it still would benefit
you and your research over time, I would imagine.
And I would say that that is a big part of Python and why Python is a good tool for science, because
it is easy to build higher level abstraction. Like coming from the MATLAB world, you basically got
MATLAB and its toolboxes, and then you got like your scripts. And like, there's like this hard divide
between like the platform and the tool and like your own work. You're used to thinking, well, these are
like the primitives provided by like the tool and here's what I have to do. But Python allows you to
build very flexibly and has this great ecosystem. I mean, I think this segues naturally into X-Ray.
Yeah.
Like many of us in say in 2014 had our own sort of private version of a code that did what X-Ray did,
thinking like that's code that needs to live in users. That's not a package provided by the ecosystem.
But then once sort of X-Ray started to catch on and we realized how powerful and how cool it was and how
well it was, what a solid foundation it had, many of us immediately stopped working on our own sort of
private X-Ray like thing and started contributing to X-Ray. And we've seen over say the past, you know,
five or six years, this really steady growth in like the capabilities, both in terms of features and
robustness like of X-Ray that we never would have done if there hadn't been that coalescence around
like, okay, we're all going to work together on this.
Yeah. And then you have these knock on effects, right? There's now other libraries and other systems
that use X-Ray. And so if you're programming against it, it's super easy to plug into it, kind of like
what Pandas and Dask are doing. Like if you program against Pandas, you kind of automatically get like
the scale up version because Dask is just Pandas, but more.
Right. And you don't have to write code to like read CSVs.
Yes, exactly. So I gave the elevator pitch for X-Ray, but let's go ahead and dive into that. And some of,
maybe, maybe give us the story for Pangeo where X-Ray is one of the sort of umbrella,
is covered under that umbrella. Yeah. So whoever wants to take it.
Yeah. I'll start, but I think, you know, just to take maybe a slight step back and say what X-Ray is
one more time, I think. So X-Ray is a package, a Python package for working with multidimensional
labeled arrays and datasets. And it integrates with NumPy and Pandas. And in many ways, you can think
of it as a multidimensional Pandas. Yeah.
And it's used really widely in the climate science community and the geosciences, but it's also used
in fields outside of the geosciences. Right. It could be finance or all sorts of things.
Yeah. So finance and biomedical and bioimaging, et cetera.
Give us a sense of like the data that you might load up off of some oceanography.
Something I think that our go-to data set for oceanography is like ocean sea surface temperature.
Satellites observe the ocean from space, infrared or microwave observations can tell how warm the water
is. That gets processed by NASA. They distribute essentially a bunch of net CDF files that are up
on like basically an HTTP or FTP server, one file per day for the past 30 years, quarter degree resolution.
Each file is a couple of, you know, 10, 10, 20 megabytes or something like that. We want to do an analysis on that data.
And so X-Ray can open that individual file, but it can also open that collection of thousands of files as one coherent data set object.
Interesting. So do you give it something like a directory and a file pattern and it just somehow does a sort and then loads them up?
Yeah.
It can do globbing, you know, it can X-Piles pass it a list. That is one of the killer features of X-Ray that I think brought a lot of people into it.
Because like, you know, we were all kind of used to like writing code around files. Like, okay, I've gone to this analysis.
Here's like a hundred files for like each file in my list of files, you know, do this. Right. And instead, the workflow changes with X-Ray. It's like, okay, open multi-file data set. Mean. Done. Right. Like, right.
And so it's just like this cognitive load that's lifted.
That's cool. Yeah. There's, especially in the data science space, I see a lot of these things and it's almost about learning about the packages and the way that you can use them.
You know, like an example that really quickly comes to mind for me is like, if I wanted to get a table out of an HTML page, out of a website, and then pull that in and like process it, I could do, go get the page with requests.
I could do some beautiful soup thing to find the table. And then I could, I don't know, try to parse it or something and then convert the elements.
If they were really supposed to be numbers, you got to parse them as numbers and then get that into some data structure.
Or you go to pandas and you say, read HTML tables bracket two or something like that. Like those kinds of things seem to appear so much in these data science libraries. Like, oh, you could do this big, long computer science thing. You could call this function over here and you got the same outcome. And it's really about knowing about that those exist. Right.
Yeah, totally.
So, you know, the workshop was Pi AOS atmosphere, ocean sciences or something like that. It was, it was a name that got dropped pretty quickly.
But the idea was that we were like 20, it was probably 20 of us that worked on X-ray and Dask mostly. And it was kind of a mix of software developers and scientists. We got together and like just kind of shared out the use cases that we were wrestling with and the problems. And out of that grew the Pangea project and a few ideas. So the, like the mission that you read on the website today is like what we wrote that weekend, which is, you know, to try to tackle a few key problems that we're facing our community.
We're facing our community, mostly big data, reproducibility and really aiming at supporting the software ecosystem that connected all those dots. And since then, the Pangea project is, has grown into a wider community project that has a lot of software packages involved, not just X-ray and Dask. That's the origin story. It really started with X-ray as the, like the beginnings. And then from there.
Okay. Interesting. Yeah. Yeah. Very cool. Maybe we could talk a little bit about the other packages, but X-ray and then there's a list of packages on the website. Iris, I know y'all don't do too much with Iris, but maybe just tell us really quick with that.
So it's at the same level of the stack as X-ray. So you're probably using either X-ray or Iris. Iris is, I would say like, it's maybe a little bit more opinionated than X-ray in the sense that it's scoped to like geo data or like data, you know, or that has things built into it that are like more specific to that domain.
Like some of the specific file formats, which I'm not familiar with, but like GRIB and those kinds of things.
No, actually X-ray gets all of those file formats.
Okay.
I think it's more about the API, like, you know, an understanding that like what latitude and longitude actually mean and like supporting things like re-gridding directly rather than say through third party packages, like we would use with X-ray.
It's a great project and it is in many ways very complimentary to X-ray and highly interoperable as well.
You can like X-ray to Iris dataset, you know, Iris dataset to X-ray.
You can think of them all as wrappers, higher level data structures around arrays, right?
So many of us have probably coded, written, if you work with NumPy at any level, you probably had a dictionary with NumPy arrays in it, like multiple different arrays you want to keep together.
And at that point, I would say like, just use X-ray whenever you're starting programming that pattern.
Yeah, because that's basically what X-ray is, right?
As how do you label it?
That's the keys.
And then multidimensional is multiple arrays, right?
Yes.
And then understanding relationships between these and then metadata, another huge part of this, right?
Like so X-ray, both X-ray and Iris and anything in the space is going to really understand metadata that comes with those things.
So things like units or, you know, conventions that tell you how the variables are related to each other.
And then it can do things with that metadata computationally, not just like drag it around, you know, for posterity, but actually leverage it to make certain syntax or certain computation.
You filter by all the ones that are tagged by state or whatever.
Interesting.
Okay.
Then the next one in the overall banner of Pangeo is Dask.
Yep.
I've had Matthew Rocklin on the show before to talk about Dask, but it's been a while.
So maybe tell folks about Dask.
Yeah.
So Dask is a, it's a library for doing parallel computing in Python and it, and it has a bunch of different containers.
And so there's Dask array, which is what X-ray uses, but there's also a Dask data frame, which does kind of parallel chunked operations on pandas data frames.
And then there's the like catch all the Dask bag, which does graph style parallel computing.
So where this comes in for X-ray is that, I mean, actually for Iris as well, since we were just talking about Iris, but the arrays in an X-ray data set can be backed by a Dask array instead of a NumPy array.
And by just kind of swapping that out, it's almost a behind the scenes swap out.
You do a dot chunk on your X-ray data set, and then your operations are going to be handled by Dask, which means they're going to be streamed through the Dask scheduler.
You'll be able to scale out to a cluster of workers and do, instead of say gigabyte style operations, you can do terabyte scale or even petabyte scales at someday data analysis.
So Dask is the thing that gives X-ray its horizontal scalability.
Yeah, very cool.
So scaling across machines.
Now, when I learned about Dask, I saw it as it's like the local pandas or the other types of things that models, but you set up a cluster and it runs there.
And then when I spoke to Matthew about it, I realized he pointed out that it's useful even on a single machine.
Some of the times, right?
If you've got a ton of data, but not enough RAM to hold it, or you even have like a pretty simple computer here as eight cores.
If I run something on pandas, I get one core worth of processing power, right?
So maybe, Joe, you're shaking your head.
Like, tell people about that use case.
Yeah, so Dask has a bunch of schedulers.
And some of those are local schedulers that run on a single machine.
And they can either use Python's multi-processing module or threading multiple threads to do computation.
It also has distributed schedulers that might live on Kubernetes or on an HPC machine.
There's now companies like Matt Rocklin has gone on to start Coiled, which has managed Dask clusters for you.
But the idea is that like at a small scale, when you're using the threaded scheduler, it's going to stream computation.
So when you say taking the average of a terabyte size array, it's going to like use its chunks and process those chunks one at a time and then aggregate those process chunks to the final result.
Yeah.
A lot of times, if it's the simple path of you go find some tutorial or example code or something on Stack Overflow, it's just like, well, first you just load this up.
You read the CSV or you load the JSON file and then you go over it like this.
And you're like, well, I have a terabyte of data and, you know, 16 gigs of RAM.
And so you need this sort of iterative streaming style to get there.
The brilliance of Dask, the game changing flavor of Dask is that for many cases, the user doesn't really have to rewrite their code at all to scale out.
And so typically with X-Ray, like we, when we teach it and we really want to like get people the sense of the power, we like start by downloading like a 10 megabyte file and opening it with X-Ray and doing some analysis.
And then they like learn the API and, you know, they use it and then, and then, and then we point it, then we sort of point people to like a massive, you know, a hundred gigabyte data set in the cloud and a Dask cluster.
And we say like, write the same code and it like just works and it's pretty fast and it is able to scale out without much, really any expertise on the user's side about distributed computing.
I love that feature.
On the other hand, I've also come around to the feeling that it can sometimes it's a double-edged sword because some things actually just fail.
If you don't think hard about the parallelization strategy, it's not magic.
It depends on the operation that you want to do.
And so the flip side of that ease of parallelization is that sometimes users will think it is Dask is smarter or more capability than it really could ever be and expect it to just automatically parallelize anything.
Even say just IO patterns that are just not parallelizable, not scalable, right?
Or other operations that are just can't be accelerated.
Yeah, it seems like it just automatically fixes the problem.
It just makes it faster with magic programming dust.
And then like, obviously some points that comes undone, right?
This portion of Talk Python To Me is brought to you by Sentry.
How would you like to remove a little stress from your life?
Do you worry that users may be encountering errors, slowdowns, or crashes with your app right now?
Would you even know it until they sent you that support email?
How much better would it be to have the error or performance details immediately sent to you,
including the call stack and values of local variables and the active user recorded in the report?
With Sentry, this is not only possible, it's simple.
In fact, we use Sentry on all the Talk Python web properties.
We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email.
That was a great email to write back.
Hey, we already saw your error and have already rolled out the fix.
Imagine their surprise.
Surprise and delight your users.
Create your Sentry account at talkpython.fm/sentry.
And if you sign up with the code talkpython, all one word, it's good for two free months of Sentry's business plan,
which will give you up to 20 times as many monthly events as well as other features.
Create better software, delight your users, and support the podcast.
Visit talkpython.fm/sentry and use the coupon code talkpython.
Hoiled, Matthew Rocklin's company that he started with some other folks, I believe.
And this is a really interesting story.
Like we talked about how you've got your X-array like code or you got your pandas like code that you just wrote for yourself.
And then by sort of adopting one of these libraries and maybe even contributing it and like building it up, you get these knock-on effects, right?
So I gave the pandas to Dask example.
And like, here's the next step in that chain, right?
Like now you have, oh, I can just spin up a cluster on the cloud automatically through coiled with like one or two lines of code because I built on Dask because I built on pandas.
You know, like that chain just keeps going of like how it all sort of this synergy between all of them.
Absolutely.
And I mean, I would say like it's not just like coincidental.
Like Matt Rocklin was at that Pangeo meeting at Columbia like in 2016 or whatever.
And actually we've watched this evolution.
So a big part of what we have been doing in Pangeo is experimenting with cloud computing.
I think a little bit earlier and more sort of in a different way than a lot of the other scientific community was.
I think we can thank Matt for that to some degree because the story with Pangeo and cloud
is that we after that workshop, we brought our first proposal to the NSF and we got a grant to like develop some of these stuff and develop Pangeo and support scientific use cases.
And what we had put into that original grant were like we had a bunch of servers that we wanted to buy to like host data and run.
That's what you do.
Like when you write a scientific grant and NSF asked us to trim our budget and we decided, OK, we will cut out these servers.
But why don't you give us some credits on the cloud?
Because at the time NSF was running this pilot program called Big Data where they were granting those like a partnership with Google and Amazon stuff.
And so we got like $100,000 worth of Google cloud credits.
And we just started playing around to see how well we could make this stack work in the cloud.
And Matt was instrumental actually at that time.
He was really involved and was helping us figure out like how to deploy stuff on the cloud.
And we learned all about Kubernetes and object storage and like all of this stuff.
And it was incredibly fortunate for us to have that because I think we really figured out a lot of stuff early on about how science, scientific research can interact with cloud computing.
And that's where a lot of our focus and energy is today.
That's cool.
Yeah, there's a lot of interesting things about large data sets, right?
You can put them, as you said, in object storage and then people can come into that cloud and like use the data without trying to download it or move it around.
Or like some of these data sets are terabytes, right?
What are you going to do to get those shared, right?
Yeah, I know some of them are petabytes at this point.
Which that's terabytes you can do.
Petabytes, that might be like a little bit beyond what your ISP is going to let you do to download.
That's right.
Yeah.
Where are you going to put it?
Or you can get a hard drive for it, right?
Where are you going to put it?
Yeah, exactly.
The thing that our work on cloud computing really unlocked for us was this idea that we could federate access, not only to compute, like everyone kind of knew, yeah, you can spin up a VM, but federating access to the data in a way that was infinitely.
That's a totally scalable, both in terms of access, but also in storage is a totally, like is a total game changer.
And so, you know, as we've gone down this rabbit hole and we've gone fairly deep at this point, the idea of putting data in object store and letting anyone in the research community access that has kind of revolutionized the way we think about what scientific computing platforms should look like going forward.
Yeah.
Yeah, absolutely.
It solves like half of the problem.
One is the computational time and power, but the other is just the storage and the data and the memory and all those kinds of things, right?
Absolutely.
And, you know, I think data providers are really reckoning now with what the cloud means, right?
Because what we had seen in geosciences and climate sciences is there were a lot of data portals out there.
An agency or a group would decide, we have a data set we want to share.
We have this data we want to share.
Let's make a portal, which was almost always sort of a highly customized website with a browser.
And maybe you had to click through to do some JavaScript and like do it like you had to interact with the browser to get data files.
And then you would like get some data files.
And maybe it seemed like a good idea.
There was reasons why they wanted to have a portal.
But like from a user point of view, especially like an expert user point of view, they're just incredibly frustrating to interact with data that way.
With cloud object storage, I linked in the chat this blog post I wrote about this, my fantasy about how if this facetious post about how to create a big data portal, there's like one step.
It's like upload your data to S3.
Right.
Exactly.
I think it's provocative.
But like I think the fact is there's a lot of vested energy expertise within the scientific community about how to build and maintain these really bespoke data access solutions.
When I think really we should be moving to a very, we should just really be using object storage and the scalability of cloud style computing to distribute scientific data.
It doesn't mean we need to just like go all in on AWS.
Although actually that's exactly what NASA has done.
You know, there's a lot of cloud storage like things that provide a really scalable base layer of storage for internet enabled computing.
There's like Wasabi alternative to Amazon.
There's like Cloudflare now is launching a data storage service, which I'm super excited about.
Interesting.
Yeah.
And you might end up with a copy of that data.
Maybe you have a copy in AWS, a copy in Azure, maybe even like Linode, DigitalOcean, places like that.
Right.
But that's only four or five copies.
Not every researcher trying to figure out how they're going to deal with it.
Right.
Exactly.
Or you outsource that sort of mirroring to, you know, a service that knows how to scale that sort of thing.
Yeah.
Another really interesting player in this space is IPFS and the, you know, distributed web.
And, you know, where we're at now is like people are very excited about in science or like about S3 and, you know, cloud computing.
But on the other hand, the scientific community is wary of being too dependent on the big tech giants.
And it always has sort of a do-it-yourself sort of distributed approach to infrastructure.
So I'm really excited about IPFS Interplanetary File System, which is a distributed yet highly performant way of sharing petabyte scale data on the internet.
Oh, that sounds really interesting.
Really quick, James out in the audience is asking, are there any Pangeo specific resources to help with that transition,
that jump from the workstation to cloud computing?
Yeah.
I think this is a good opportunity to show off and talk about the list of tutorials and examples that we have.
So I think, you know, Pangeo has a collection of Jupyter notebooks that show how to use.
Yeah.
So this is gallery.pangeo.io.
There's a list of Jupyter notebooks here that walk through kind of real world examples of working with large geoscientific data in the cloud.
And so I'd encourage people that are listening to pull this site up and take a look.
And I'll put a link in the show notes if you can find it as well.
Yeah.
So I think this is a good example of like one of the best resources we can point folks to.
Okay.
But I mean, to get a little bit more specific, the idea is actually you don't have to change very much at all about your workflow when moving to the cloud.
Right.
That's what we're aiming for with Pangeo.
And a key part of this and sort of that another pillar of Pangeo we haven't discussed yet is Jupyter.
So Jupyter is a key part of our effort.
We work very closely with the Jupyter developers and also the team at 2i2c, who I know you've talked to recently.
And Jupyter has been, I think, an amazing sort of Trojan horse for like cloud computing because the way when you use Jupyter for the first time, it launches up a notebook in your browser.
And honestly, the hardest way to use Jupyter is to try to use it locally because you've got to install it and configure it and run it and get.
Exactly.
The cloud story is just even easier.
Exactly.
So we now have the scientific community who like scientists, you know, huge number of scientists in many different languages are all just used to the idea that we're going to do our science in our browser through this type of, you know, IDE, essentially.
And JupyterLab especially has so many more features than classic notebook that make for a really rich, interactive scientific computing environment.
So then moving the work to the cloud is trivial.
I mean, for the user, you know, and so in Pangeo, we operate some cloud-based Jupyter hubs.
And also we have an operating binder.
And those Jupyter hubs, basically, you just log on like and anyone out there can actually sign up for the Pangeo hubs or apply to be to get access to these hubs.
And then you just have a notebook environment in the cloud.
Of course, just having your notebook in the cloud is not that cool.
But what we can augment it with are some capabilities to run DAS.
So we use DAS Gateway in those hubs as a DAS deployment solution.
But, you know, Coiled is another example of a DAS deployment solution.
And then the key, though, what is going to bring scientists to the cloud is that data, right?
So that is what makes this appealing and game-changing.
The fact that now you log into this hub.
Okay, you're in Google Cloud US Central 1.
We got a petabyte of data from the World Climate Research Program coupled model enter comparison program project sitting there.
Organized, analysis ready that you can start doing science with.
So when before you know that, if a grad student, say, would decide, okay, I'm going to work with these cloud models and do this research project, they would literally spend months downloading, organizing, and sorting that data on a computer before they can get started.
Now you can start it in five minutes and be processing data.
And that's amazing.
That's what gets me excited and motivates me to devote energy to this project.
Maybe that also involved writing a grant so that you could get enough compute to locally hold and work on that.
And you got to wait.
Okay, I'm going to order our Silicon Graphics or a Cray or whatever it is you're getting, you know, whatever the supercomputers are these days.
And they'll wait for some big thing to show up.
Or you fire up a notebook in AWS.
Take your pick, right?
I suspect this is also democratized computing somewhat as well, right?
You don't need as much compute to set up something like this and access that existing cloud database.
That's true.
And I think part of that is we've separated in the cloud model of separation of concerns.
The storage is not necessarily directly attached to compute.
Whereas like in a supercomputing center, it's all one warehouse, right?
Yeah.
And so, yeah, like if you're just, if you're doing a small problem, you get a small VM or you get a small cluster.
A small DAS cluster.
If you're doing a big problem, you scale out.
Right.
And so you can sort your, or you can arrange your compute infrastructure appropriate to the problem you're working on.
And the other thing is the way we're storing the data allows for partial queries of these large array.
You know, so the data that Ryan was talking about, the CMIP 6 data is a petabyte in scale, but you don't have to open the whole thing and you don't have to load the whole thing.
We're able to slice into that and grab out just the parts that are interesting for the research project that's being done.
Right.
Exactly.
That's, that's awesome.
One thing I did want to ask you to about real quick, or we're getting short on time here, but do projects like Jupyter Lite, which is Jupyter, but running on WebAssembly in the browser or the Python stack a little bit running on the browser or PyIoDied.
Do these projects offer any benefits to you all or are you tracking them?
Are you interested?
It's super cool.
Um, Jupyter Lite and PyIoDied, it really lowers the bar to providing just like getting something up and running.
The motivations for getting into Pangeo, for starting Pangeo, a big part of it was big data.
We have large data sets, right?
And so we want to do data approximate computing.
So by putting a hub in the cloud, we're putting our compute next to the data.
PyIoDied actually takes it back to the laptop.
Yeah, yeah.
This doesn't solve the data problem.
This kind of wrecks that, but it does give computational capabilities without.
And if you couple that with something like Coiled or any Dask solution where you can actually then call out to a data processing layer that isn't.
Interesting.
It's, it will, it would make the need for us to operate those Jupyter hubs potentially go away or reduce or go away.
Oh, that's interesting.
So you've got the, the Dask cluster or whatever next to the data in the cloud.
And this is just handling the results of all that.
Okay.
I hadn't thought about combining those in that way.
Very cool.
If you want to process like many terabytes of data, you're not going to do it in your browser.
You're not going to do it in your laptop at all.
You do need a big computer, right?
Yeah.
But still, like it, it certainly expands what's possible larger than like maybe the first impressions.
Oh, I was going to say a quick shout out.
Recently added a Jupyter Lite example tutorial to the X-Ray homepage at xray.dev.
So if folks want to go try out xray really quick without having to start up a Jupyter lab server or something, it's there and you can run through.
Oh, that's fantastic.
Yeah.
We've got binder, which sort of creates a cloud instance to run all these examples, but a lot of them could actually just run like this, which is great.
Yeah.
It makes it a lot simpler.
Yeah.
All right.
We could talk for much longer, but we also know that we don't have too much time left.
So let me ask you both real quickly the final two questions.
Joe, you can go first.
You're going to write some code.
What Python code, what editor do you use?
VS Code.
All right.
Or Vim if I can't.
Okay.
I use Atom and I feel like I'm behind the times, but like that's what I use.
That's like OG VS Code.
It gets what I need to do done, but I feel like I'm missing out on things.
So I probably need to upgrade.
I do feel like my development environment is increasingly owned by Microsoft.
And so I have like some mild reluctance to switch to VS Code.
Sure.
I hear you.
Awesome.
And then notable PyPI package, some library you've come across lately that you thought was awesome.
I mean, obviously, shout out to Pangio and all of it.
But it's not a package.
You can't pick.
No, I know.
Yeah, I know.
I'm going to go with one of my favorites, which is not something I came across recently, but I think everybody should know about it.
Yeah, that works as well.
It's FSSpec.
And it's a library for accessing data across a bunch of different file storage systems.
And it is a game changer for working with remote data.
Everyone should know about it.
Yeah, absolutely.
That's a super interesting one.
Basically, you can connect it to all these different backends and stuff, right?
I don't remember where to find them.
But yeah, like you could connect S3 like it was a file and stuff like that, right?
Yep, exactly.
Yeah, fantastic.
All right, Ryan.
Well, mine is a shameless self-promotion, but it's for a new project we have called Pangio Forge, which is basically an ETL tool for this X-ray scientific data space.
Right.
So what we found is that a lot of the ETL tools that exist for business style data analytics don't necessarily play well with our multidimensional data model that we use in geosciences and sciences more broadly.
And so we're building this open source Python package called Pangio Forge recipes that is designed to help us with all this data movement, data transformation that needs to happen as we're migrating so many sort of legacy data sets into this cloud native format.
That looks fantastic.
All right.
Yeah.
Good shout out.
And we'll put a link to that so people can check it out.
All right.
Joe, Ryan, it's been a lot of fun.
A quick final call to action.
People want to get started with Pangio.
What do you say?
Come to our forum.
Yeah, you mentioned before we hit record, you mentioned that the discuss page is like really where the action is at right now.
The discuss forum, right?
Discourse.
Discourse, sorry, not discuss.
Yeah, discourse.
The tools and the stuff is self-documenting on the website.
But what we really emphasize about Pangio is the community aspect of it.
We are not just trying to build a tool and like put it out there.
You know, we're really trying to build a community where scientists are talking to software developers, are talking to infrastructure maintainers, are talking to data providers,
and are collectively sort of trying to keep this flywheel spinning of innovation and development, ultimately with the goal of empowering more scientific discoveries.
And so if you have questions, if you have, if you stop breaks, if you don't know if it's the right tool for you, this forum is where we can welcome you.
We don't have a Slack.
We try to be more open than as a community than a Slack.
So this is where I should have.
I can second that.
It's a good idea.
Awesome.
And then, Joe, you also wanted to throw out xray.dev, right?
Yeah.
So there's, yeah, exactly.
This is a relatively new site that sits on top of our documentation site.
But there's the Jupyter Lite interface is down below the fold.
And it's a great starting point.
Thank you both for being here.
This has been really interesting.
And thanks for all the hard work.
Thanks for having us.
Thank you for creating this.
Yep.
You bet.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Add high-performance, multi-party video calls to any app or website with SignalWire.
Visit talkpython.fm/SignalWire and mention that you came from Talk Python to Me to get started and grab those free credits.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython, all one word.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app 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.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
We'll talk to you soon.