Telescopes have been fundamental in our understanding of our place in the universe.
And when you think about images that have shaped our modern view of space,
you probably think about Hubble.
But just this year, the JWST or James Webb Space Telescope was launched.
JWST will go far beyond what Hubble has discovered.
And did you know that Python is used extensively in the whole data pipeline of JWST?
We have two great guests here to tell us all about it, Megan Soze and Mike Swam.
This is Talk Python to Me, episode 357, recorded February 23rd, 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 Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube
to get notified about upcoming shows and be part of that episode.
This episode is brought to you by Datadog and Stack Overflow.
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.
Megan and Mike, welcome to Talk Python to Me.
We're happy to be here.
It's great to have you here.
I'm such a fan of space and just it's amazing to think about our place in the universe
and where we are.
And so much of that has been revealed really through telescopes, right?
From the very beginning of like, oh, look, the sun doesn't rotate around us.
How weird to, you know, the universe is expanding with what Hubble did
or just all the amazing discoveries we've had, the exoplanets and whatnot.
So super cool.
And if we're going to mix Python into that, it's definitely an interesting thing to do.
So I'm happy to have you both here to talk about that.
Yeah, we're happy to join you.
It's a pleasure.
Yeah, it's great.
Let's just really quickly before we get into the topics,
maybe start with just a little bit of a story on your background.
Now, Megan, how'd you get into programming and find your way over to Python?
Yeah, so programming.
I started young and it was mostly because I was jealous of some of the other kids.
This is the early 80s that had access to the new Atari systems, the new Coleco Visions.
And I didn't really have that.
I wanted to be able to play games and do those types of things.
And as it turned out, my dad had just bought one of these new computers in Osborne,
which is kind of one of the early personal laptops.
That was one of the very early ones.
It might be the first laptop, a very heavy laptop, though.
Probably not as good battery life as today either, I would suspect.
I don't think there's no battery life.
Yeah.
And it only had a small green screen and you couldn't display graphics.
But I was determined I was going to play a game on it.
So I found this programming book in BASIC for microprocessors and followed along,
learned what it was doing to create responses on the screen.
I ended up making things like Mad Libs and choose your own adventure and ASCII art and
stuff like that.
And just learning what the commands I was doing really did.
So that got me into programming that I kind of just did that on and off.
It was really strange, even though I was always working with computers.
When I hit college, nobody ever suggested to me that I should do computer science or that
I should be a programmer or that I should do this other thing.
So I went along with some of my other interests, which were astronomy and physics and music.
But even in astronomy software and software engineering and working with computers is a must.
And after I started working at the Institute for a few years, Python started to become a much more used language.
It's something that could provide real benefit for the scientific community.
And so I started learning that.
And that's how I got into Python.
Wow, fantastic.
The days of just holding up a telescope and looking at stuff, those are pretty long gone, right?
Yeah, they're pretty long gone.
In fact, most astronomers don't even get to go to the telescope on the ground anymore.
There's a lot of remote observing.
It was starting to switch over when I was in college.
It's much, much heavier now.
Yeah.
I can imagine.
What a bummer.
Those are amazing places.
Yeah.
How about you?
How do you get into programming, Python?
Yeah, for me, I dabbed a toe in it in high school with a Fortran class.
We actually got bussed over to another school to run our deck of cards through someone else's computer.
Oh, with cards.
That's another level right there.
I'm that ancient.
And then in college, a few classes here and there.
And then when I got out, one of the only skills I had was programming.
So I had a math degree.
And so I started with programming in Fortran at the start, but then got into other languages
and eventually got to Space Telescope in 1996 and have been here ever since.
It started with Python in about 2002.
There was a software conference called ADAS, A-D-A-S-S, Astronomy, Data Analysis and Software
Systems.
And we put one on, the institute that I work at, put one on in 2002 in Baltimore.
And Python was really a highlight of that conference.
It was really coming into its own.
And that just kind of broke the door down for everyone at the institute.
Oh, that's cool.
Behind one of our founders, Perry Greenfield, who works at the institute, is very, very big
in the Python community.
And he kind of led the way and we all followed.
Right on.
Well, it's certainly an amazing language for data science and for working with things like
these telescopes and whatnot.
So it has a special blend of approachability, but you can actually do quite a bit of real
stuff with it.
Whereas, you know, so many other languages are either approachable or you can do real stuff,
but not both.
Yeah.
It also cuts down a lot on development time and lines of code and stuff like that, which
makes it a lot easier to maintain larger systems that can handle the Python.
Yeah, absolutely.
I was so impressed with the clarity.
When you looked at a piece of Python code, you stripped away all the syntax and all the
language decorations and it was just, the design was staring at you.
So to me, it's the simplicity of it that's the best feature.
Yeah, absolutely.
So let's start a conversation maybe by talking about where you two work at the Space Telescope
Science Institute.
It just sounds so amazing.
That is a cool thing.
Yeah.
So what do you do there?
Megan, you want to go first?
Yeah, sure.
So right now I'm the technical lead for the data management system that's going to be accepting
and processing and distributing all of the data that we're getting from one of the next
big telescopes, the Nancy Gates Roman Space Telescope.
So my day-to-day job is making sure that all that is designed and functioning and data is
flowing through and the software we're going to write for scientists to do analysis of that
data will run and is appropriate and accessible.
That's kind of my, that's my day-to-day.
Before that, I worked heavily on post-pipeline scientific analysis processing software.
So visualization tools, data analysis tools, things that really the astronomy community
uses after we've constructed the data for them from the telescope.
Okay.
Tell us just a little bit about the data story of this.
There must be a lot of data coming off of these newer telescopes with their huge resolution.
Yeah.
So there is a lot of data coming down.
The detectors on board JWST are 2,000 pixels by 2,000 pixels.
And there's a lot of them and there's a lot of instruments.
And so we have to be able to manage all of that data stream coming through.
And I might let Mike talk a little bit here since he works heavily on the ops side of the house,
helping with managing that data.
All right, Mike.
Yeah.
Take it away.
What's your role at ST Sci?
My role is, yeah, it is a team lead for the data processing team, also a scrum lead.
We use the agile approach to software development.
And I'm focused completely on JWST science data processing and guider data processing.
The data comes down to us through the deep space network of NASA and hits the ground,
comes up to us at Baltimore.
We have the control center right at the building, so they're actually talking to the observatory
through the tel, right through there, our main building.
And then the data feeds down to our processing systems.
And that's where my code comes in.
Making sure we got all the data, completeness checking, sending the data through the pipelines
and the processing systems with the right processing recipe so that we get the right kind of data
products out and getting them into our archive.
The Institute has a well-known archive for astronomy data.
And that's where a lot of astronomers come to do research and find data sets that they
can use in their science.
A lot of that data is public, right?
It is.
It is very much so.
There's a proprietary period for some kinds of data so that scientists have a chance to
write their special papers that they proposed for.
But a lot of data is made immediately public.
And then other data becomes public after a bit of a window.
Oh, interesting.
So you might write a proposal for time on web or one of the telescopes.
And then if that's approved, then you get your time, then you get your data.
And of course, it wouldn't make sense to just instantly publish that because that's part of
your work, right?
Yeah.
And so this is actually, you know, pieces of the entire process.
The whole world of astronomers is allowed to propose to use these telescopes.
And there's a telescope review process that happens where they submit their suggestions.
This is what I want to do.
This is how awesome the data is going to be.
This is what I'm going to provide to the community and the discoveries I think I'll make.
And a team of experts, you know, agrees and decides how much time everybody is going to get.
And we have a lot of tools on what you might think of as the front end of this process
to help them figure out, you know, how long do the observations have to be?
If I'm looking through these filters and these wavelengths, what kind of errors am I going
to get?
You know, what's the exposure time?
How should I most effectively use the telescope time to get the science out?
Because telescope time is always, it's gold, right?
Right.
Absolutely.
There's one and only one of these things, right?
Yeah.
This particular one.
I didn't really think about that you, for asking different types of questions, there
was a different amount of time that you might need.
I mean, obviously, if you're going to stare at space for a certain amount of time, it's
going to take that time.
But I hadn't really thought about the different processing pipelines might require more data
to get the right level of accuracy and stuff.
That's pretty interesting.
Yeah.
So it really does depend on what you want to get out of it.
When you insert in different wavelengths, you have to look at those things for a long enough
amount of time to collect the light, to get statistical certainty, to get detections.
But then you have to play that against the fact that as you look longer and deeper, your
field might get more crowded because you'll be able to pick up light from more distant objects.
You may have things that are called cosmic rays, extra energy that gets added into the
detector that you don't want.
That's not from your object, that's just messing up your data.
And the pipelines take these things into account.
We look for things that are, oh, this is not coming from the object.
This is coming from something in space that we don't want to detect right now or something
that is being imparted by the instrument onto the data.
And we want to remove the instrumental signatures.
So that's what a lot of the processing software tries to look at.
Yeah.
Fantastic.
Mike, anything you want to add to that?
Just one other kind of data is time-dependent data.
You may need to look at objects over time, either calendar time or even many hours or many
days to see variability.
And that's a big part of some of the data sets is they just stretch on for time so that you can look for
planetary transits or flares or various phenomena that might vary over time.
Yeah.
How interesting.
One of the goals that Webb is trying to solve is to detect exoplanets, right?
And for those, you've got to watch multiple years of whatever that planet's year orbital
time is, right?
If it takes it three months to go around, you've got to watch the star for several three-month
periods, right?
Well, and even in the case that you don't know that the stars have planets, you want to find
new ones.
You need to go back and look at that star multiple times so that you can detect that difference
in the light that it's emitting.
So when the planet goes across the star amount, some light is going to be dimmed by that.
Or if you're looking at spectroscopy, you might see the starlight passing through the atmosphere
of the planet itself.
Yeah.
Fantastic.
All right.
I want to dive into the Python side, given that that's what most people are interested in.
But before we get into that, let's just talk real briefly about what are some of the science
missions and how is this, say, different than Hubble?
It looks really different than Hubble, right?
It's this bunch of hexagon gold plates that unfold instead of being a tube like a traditional,
even, you know, the sort of space telescope like Hubble is.
It's got a tennis court sized shield around it and stuff.
So whoever wants to jump in, tell us a bit about just like what is the goal and the science
of Webb?
Yeah.
So Webb is really the largest space telescope.
It does have segmented mirrors, 18 of them, that can be adjusted to make sure that the focus
is good.
It's something like six meters across.
It's really big.
It's six and a half meters across the mirror.
I think it's something like 21 feet in diameter, something like that.
One of the things that makes it different from Hubble is not only the size of the mirror and
the size of the telescope, but Hubble orbits the Earth.
And JWST is demonstrably not orbiting the Earth.
It's not very close at all.
It's out at the second Lagrangian point, which is a more stable point that things orbiting into
the Earth's sun system tend to collect at.
And it's not even at that point.
It's orbiting around that point and facing away from the Earth.
And so one of the things that's really important for Webb is that it stays cool, that its instruments
stay cool.
And that's why it has this big sun shield.
And so the cold side of the telescope is where we have all of our instrument packages.
And that allows it to pick up this infrared wavelength of light, which is sensitive to heat.
And it allows it to do the science that we need to do to look at dust and look through dust and look all the way back, you know, to the very earliest time just after the Big Bang when light was starting to be visible, to collect and start to form objects and stuff like that.
So the design of the telescope is very much to enable the science that's possible with it.
And Hubble uses visible light?
Is that the difference?
So Hubble has a range.
Hubble actually has instrumentation that looks at UV, visible and then near infrared.
So it has a little bit of everything.
JWST also looks at near infrared, but it goes much further out into the mid infrared as well.
And I guess that goes through dust clouds and things like that better.
It can.
So you can switch between the different wavelengths of light depending on what types of phenomena you want to see.
But also because we want to look very far back in time, what happens and what enables us to do that is the red shifting of the light.
So because after the Big Bang and the expansion of the universe, the light gets stretched by the expansion of space.
To look back in time, you want to look at the light that is of that similar wavelength that's been stretched.
So that's why we're looking in the infrared wavelengths.
This portion of Talk Python to Me is brought to you by Datadog.
Let me ask you a question.
Are you having trouble locating the bug in your app's code or identifying the cause of your application's latency?
Track your Python app's performance with end-to-end tracing using Datadog's Application Performance Monitoring, or APM.
Datadog's APM generates detailed flame graphs to help you debug and optimize your Python code by tracing requests across web servers,
database calls, and services in your environment.
Without switching tools for context, you can navigate seamlessly to related logs and metrics within the same UI to troubleshoot errors fast.
Break down inefficient silos between your dev and ops teams and visualize your application's performance end-to-end.
Allow your development team to focus on revenue-generating projects and releasing applications faster to market.
Get started with a free trial of Datadog APM at talkpython.fm/Datadog, or just click the link in your podcast player show notes.
Thank you so much to Datadog for supporting the show.
So what are some of the missions?
I talked about the, you know, we talked about the exoplanet a bit.
Exoplanets, galaxy history, evolution.
Star formation.
Looking at the chemical composition of the galaxies and of stars.
So it really uses this combination of spectroscopy, imaging, and coronography.
And the coronography is excellent for exoplanets because it allows you to put, you know, basically put a stopper in front of the star
and look for really, really dim things that are very close to it.
Yeah.
Solar system objects as well, and even things out in the comet, you know, or cloud.
On the Kuiper belt.
Things that we just can't see.
We don't have anything that can get out there in the infrared like this telescope we'll be able to.
That's going to be super exciting.
Hubble really changed people's view of the world, right?
I'm seeing all the, like the sky full of galaxies and stuff like that.
What do you think we're going to learn?
I mean, maybe it's too hard to predict, but what do you think is going to be surprising?
Or what types of things do you think we're going to learn and change our perspective with this?
I guess what I hear from most of the scientists is they know they're going to find out things that they never even thought of
because that's what Hubble brought.
And when you put something up that's this groundbreaking, that it goes so far beyond what we can currently do,
there's going to be just surprises that are just going to blow people's minds because they did not think that things were even possible.
Hubble basically was involved in finding the acceleration of the universe, expansion, and that wasn't even conceived of.
So things that are groundbreaking and just never thought of, the astronomers are open to those,
and they're waiting for the data to come in to start to get to look.
Yeah, fantastic.
All right, speaking of data, let's start talking about that side, Mike.
You said the data comes in over the Deep Space Network.
Is that my name?
Yeah, the Deep Space Network.
Tell us about the kind of data coming in and how that all works.
Sure. The Deep Space Network is what we use to talk to the observatory.
We get a couple contacts.
Well, eventually, when it's in steady state operations, we'll get a couple contacts a day where it'll download the data to us.
Right now, we're in fairly steady contact.
There are three ground stations around the world in Australia, California, and Spain that kind of give nearly continuous coverage.
So they're getting the data down.
What kind of bandwidth can you get on this network?
These networks are big antennas, and we share this with other missions, with other things that are in space that need to communicate.
Like Mars rovers and whatnot.
Like Mars rovers and stuff.
And they typically operate in the KA and S-band regions.
Yeah, cool.
All right.
I'm sorry.
I didn't mean to derail you, Mike.
Go ahead.
No, all good.
So the data comes down to the Deep Space Network facilities.
It gets transferred up to the Institute, which is in Baltimore, to our flight ops team, the flight observation system.
They get the data in several forms.
They get binary files right off the flight data recorders.
There's a recorder that captures both science data from the science instruments and engineering data that's monitoring the state of the telescope temperatures and pressures and various things.
Right, of course.
Because there's a whole control center going, it's focused right, it's still running, and things like that.
Absolutely.
Yeah.
They have the health and safety of the observatory and then the science as well.
So we get those binary files that come up.
We get auxiliary files that are processed on the ground.
We take the engineering data that comes down, extract out some really key parameters that are necessary for the data processing and put those in special files and send those over to our data processing system, along with kind of a summary of what the telescope was doing since we last contacted.
So we know, I'd observe these things and these observations worked, these had problems, gives us kind of a status of things.
And the other kind of data that we absolutely need is called ephemeris data.
It tells us exactly where the telescope was at any given time, which can be important for some types of science.
So all that data flows our way in files.
We use Python tasks to whole a common disk area that files are dumped in and pick them up and transfer them to our processing system.
So the telescopes receive the data, that gets processed probably at the tele, not the telescope.
Ground stations.
They receive it.
Yeah.
And then that gets sent probably over the internet, gets dropped into some like a local file or some cloud storage.
You're watching that and then Python picks it up from there.
That's right.
We pick it up.
We segregate what kind of data each is, send it on for various kinds of processing.
We put a lot of that, those data files, right as they come in the door in our archive.
So if we need to get them back out to look at them later, we can.
We use a system of, for kind of distributing the processing called HT Condor.
It's made by the University of Wisconsin and it lets us distribute the processing over a big network of machines.
This was developed even before the cloud came into bay and now the cloud's just part of it.
So we use that system to span out the data processing of these various types of files.
And we have a lot of kind of data completeness checking that we do in Python where we got to register what came in, whether we got all the packets.
The data can come in different orders.
It can be split up different ways in the recorder.
And you have to kind of do a bunch of data counting before you can send it down the pipeline for processing because otherwise you'll have holes in it and the processing will give you the best product.
So we do all that pre-data accounting analysis and when we've got something that's got all the parts, we send it on down the pipeline with a particular processing recipe that tells the pipeline to apply these exact calibration recipes, make these exact kinds of files and get them into our archive for the scientists to retrieve and do science with.
That's really interesting.
So you're doing some of the error checks and all that kind of data cleaning stuff for them before they have to pick it up.
Well, we also need to check to make sure that there wasn't an error in the transmission of the data that we got.
Everything off the telescope that we thought we were going to get, whether things need to be retransmated.
And we're recording all the information about the instrumentation surrounding the detectors, what the temperatures are on the telescope and saving that and associating it with the data so that when scientists are looking at it, they can make correlations with the different things that they see.
Oh, nice.
Teddy, the audience has a question that's pretty related to that.
How do you manage potential disruption in data transfer?
Like if you lose the connection?
Do you all have to worry about that or is that handled like below the layer?
Okay.
We do.
It does happen.
It is handled upstream from us.
The deep space network has that capability.
Our flight ops team has to get them sometimes to retransmit the data.
If we got it on the ground, but we just didn't get it to our institute, we can get it resent from another ground station.
But if it really didn't make it all the way down from the observatory, then they've got to go back on the next contact pass and get it to retransmit to the ground.
Yeah.
So there must be some kind of protocol exchange over the deep space network, right, that sort of takes care of that for you.
Yep.
And as Megan said, that's a shared resource.
So if they happen to be talking to the Mars rover or they happen to be talking to something else, we got to get in line with everyone else until we get our turn again.
Sure.
Also related to that is, you know, what's the latency between the first piece of data sent and the first one received?
I mean, we are at great distances talking about the speed of, you know, limited by the speed of light, right?
So it's not milliseconds, I'm sure.
Yeah.
Megan, do you recall what the travel time deal to is?
I don't recall, honestly.
I don't know.
Probably by the time we get it, we're talking minutes, some range of minutes, but I haven't calculated it recently.
Yeah.
Very interesting.
I mean, when we talk about data, you know, you may take pictures with your camera, with a CCD in your camera, and you'll see that picture immediately.
And it's a square, and it looks like the scene that you got.
But when Mike was talking about, you know, we're waiting for the pieces of the data to come, that square gets chopped up on board the telescope and sent to us in little tiny pieces, and we have to reconstruct it.
Yeah.
You don't do it all at once, right?
And the other part of that analogy is if you hold your camera up and you take a picture of the sky, it's just a picture.
We add all kinds of what we call metadata, supplementary data to that image that tells where it was pointed in the sky, what filters were in use on the observatory, what astronomer asked for this data, what data grouping is it part of?
They do groupings in what they call proposals.
And so we have all this extra data that we put into the files so that someone coming in to our archive who didn't propose the data can still extract it and get some understanding of what was done, how that piece of observation was set up.
That's a good idea, of course, because if somebody says, here's a directory full of large JPEGs, do science now, right?
That's, well, hold on.
Exactly.
They're beautiful and they're almost useless.
Yeah.
They're almost useless for science.
Yeah, absolutely.
They would still make a good coffee table book, though, probably.
Once they were cleaned up of the cosmic rays and all those things that Megan talked about.
Once you combine all the multiple filter images, you get the pretty colors.
Yeah, I bet.
Yeah, those are amazing.
Samperia asks, you know, what's the max onboard storage in case, like, the data, if there's an extended period where you can't get to it?
You know, how long will this thing run before it's just hard drive fills up?
Meg, do you remember the capacity for the recorder?
I know, because I have Roman in my head right now, so I don't remember the JWST capacity.
But they take that into account, and that's how they've scheduled our contacts and downlinks with the deep space network so that we can get the data off in a reasonable time.
And it's not affecting, you know, scheduling of new observations.
So they've done a lot of work.
And a lot of the work that we've done with Hubble in the last 30 years, because we do scheduling and data processing on Hubble, has allowed us to understand how to best optimize those types of things.
Yeah, very interesting.
Yeah, you must have a lot of experience from Hubble because that's a lot of data as well.
I was wondering how much computing happens on the telescope versus how much is it just a receptor and a transmitter?
There is a little bit that happens on board, JWST, especially in the instruments.
Meg probably knows more of the details of some of the infrared instruments, but they do image differencing and summations.
Infrared detectors build up their signal over time.
And rather than send all those bits to the ground, there are some on-board calculations that are done so that they send a bit less to the ground than they actually collected.
Yeah, so one of the things that's different about IR instruments than UViz CCDs is that we don't, every time, there is no shutter in the IR.
Every time we want to know what the detector's collecting, we kind of ask it really nicely.
What's the voltage of this pixel?
Then we ask it again, and we ask it a whole bunch more times.
And that's the data that we send down.
And knowing how that signal is accumulating in the pixel without removing the signal from the pixel allows us to do cool things with IR data that allow us to reject the cosmic rays that may have come during the course of the exposure and stuff like that.
Nice.
Do you have to do, like, stabilization?
I know the thing is probably pretty stable out there, but it's also looking really far away.
Yeah, stabilization, yeah, it is looking far away.
And it is mostly stable.
Where it is orbiting around L2 is not a completely stable orbit.
And so they do have to do station keeping, which I believe fires rockets to make sure that it's in the correct orbit.
Yeah, one of the big pieces of news that was really great was ESA, the European Space Agency who launched this, did an excellent job of getting it right on target.
So it didn't have to correct much, which means it has extra fuel to run longer to do that, right?
Exactly.
They did an amazing job with that launch.
That was like a flawless launch.
It was really, really cool.
Fantastic.
All right, a real-time follow-up.
We've got Adam out in the audience says,
JWST can store at least 65 gigs of science data.
Downloads occur in two four-hour contacts per day where each can transmit 20.6 gigs of data.
How about that?
Nice.
When we reach steady state science operations, that's probably correct.
Yeah, right now we're contacting a little more often because as they're going through commissioning, they really need to interact with the observatory much more often.
When we get steady state operations, they'll send plans up to the observatory.
And the observatory will just tick through the plan.
It'll look at this star.
It'll throw these filters in it.
It'll turn to this galaxy.
Look at these filters.
Right.
Go look at this planet.
And it'll basically do it a program where right now they're interacting much more often with the observatory.
So if you tell it to stare at this spot, this blank dark spot in the sky for four hours, you don't need to check in with it as frequently as long as it's...
Exactly.
Yeah.
If you told it to stare at that spot and something went wrong, James, the web telescope is smart enough to skip ahead and go to the next thing in the schedule where Hubble was very ground dependent.
Everything Hubble did had to be told from the ground.
And James was T is a little bit more automated where it will, if it's got a problem with something it's trying to do, it'll just skip ahead to the next thing and someone else will reschedule that later on.
So I heard that there's some kind of JavaScript stuff running actually on the telescope.
Is there any Python happening there or is the Python story really once the data gets back here?
There's no Python on the telescope.
There is JavaScript on the telescope.
It is a forked private version of JavaScript from a while ago, I believe.
There was a study done to think about what's the best way to do instrument commanding and that's what I believe is chosen.
Yeah.
Interesting.
Yeah, it's fine.
It doesn't really have numbers, but I guess you don't need numbers for science.
So it's okay.
Well, so, I mean, when you think about the volumes of data that are coming down from the telescope, we're also transmitting, you know, the science pixels as integers.
They're unsigned integer arrays.
And then when we do the actual processing, those are expanded into floating point.
So there's expansion that happens on our end for processing and storage and analysis.
Yeah.
Cool.
Mike, you mentioned this HT Condor.
Maybe tell us a bit more about this.
Is this something that people would find generally useful outside of telescopes?
Absolutely.
It's a very generic product developed by the University of Wisconsin.
Back in the day, they developed it because they had all these computers sitting around with people's desktops that they wanted to make use of.
You know, people were using them for three or four hours a day and then going off to lunch and off to meetings and the computers were sitting there.
And they used this system as a way to harness those cycles to the point where if no one's sitting at a computer, Condor could tell it could drop a job on that computer, run until the person comes back.
As soon as they hit a keystroke, the job would leave that computer and if needed, go off and finish its work somewhere else.
So it started in that realm and they just expanded and expanded over the years.
Kind of like SETI at home or one of these sort of grid computing stories.
Exactly.
It started in that realm.
Now it can process over full universities using all the machines at a university, research clusters.
They're government initiatives that have grid setups.
Now the commercial clouds are involved.
They have interfaces to AWS and Microsoft Cloud and a whole bunch of others.
So they really expanded their access.
It's highly used.
The realm that pushes it the most are the ones that do the...
Oh, Megan, what is the big science that just came out last year?
I'm throwing a blank.
The big science that just came out?
Yeah, the detectors where they found...
Not LIGO.
LIGO, thank you.
Oh, that's right.
Something about space and black holes, yeah.
The computing demands of those detectors are just...
They make JDBST look like a pen.
Oh, really?
Computing on your pen.
So they're really off the charts.
They need so many cores and clusters to do their computations.
And this is one of the only systems...
Condor is one of the only systems around that can get them the access to the cores they need.
And it's highly used in the LIGO community.
This portion of Talk Python to Me is brought to you by the Stack Overflow podcast.
There are few places more significant to software developers
than Stack Overflow.
But did you know they have a podcast?
For a dozen years, the Stack Overflow podcast has been exploring what it means to be a developer
and how the art and practice of software programming is changing our world.
Are you wondering which skills you need to break into the world of technology or level up as a developer?
Curious how the tools and frameworks you use every day were created?
The Stack Overflow podcast is your resource for tough coding questions
and your home for candid conversations with guests from leading tech companies
about the art and practice of programming.
From Rails to React, from Java to Python,
the Stack Overflow podcast will help you understand how technology is made and where it's headed.
Hosted by Ben Popper, Cassidy Williams, Matt Kierninder, and Sierra Ford,
the Stack Overflow podcast is your home for all things code.
You'll find new episodes twice a week wherever you get your podcasts.
Just visit talkpython.fm/stackoverflow and click your podcast player icon to subscribe.
And one more thing.
I know you're a podcast veteran and you could just open up your favorite podcast app
and search for the Stack Overflow podcast and subscribe there.
But our sponsors continue to support us when they see results
and they'll only know you're interested from Talk Python if you use our link.
So if you plan on listening, do use our link, talkpython.fm/stackoverflow to get started.
Thank you to Stack Overflow for sponsoring the show.
And I think Python too is a huge part of that LIGO result.
It is.
They use a lot of Python.
Yeah, that's awesome.
Condor has a full Python interface.
So you can talk Python right to Condor, import the package, and you're off and running.
Yeah, that's really neat.
Just pip install or Condor install HD Condor and off it goes, right?
Something like that?
Yep.
Pip install power.
Awesome.
You mentioned that it takes advantage of these computers, which are kind of sitting idle.
And of course, we've got like folding at home and we've got SETI at home,
those types of things, which they seem to have gone away, which I think it's a little bit sad,
actually.
But there's been these things where it's like, well, if a personal computer is sitting around
idle and we've got a bunch of them in an office or a university or whatever, then we could use them.
That's great, right?
But you also mentioned the cloud.
And I guess I had never really thought about it, but I know the cloud providers don't want this
from you.
But if you pay for a virtual machine, there's a good chance that it's sitting there doing 20%
of what it could do, right?
So you could actually, if you've got 10 or 100 virtual machines running in the cloud, you could
say, you know what?
Whatever extra capacity you have, I'm going to use that for this other sort of scheduling
service.
The good thing about astronomy is most of it doesn't have to happen in real time.
So we can buy up the cheap cycles where the machines are not being used one hour on a clock
and get good deals to go off and do our reprocessing and processing that has to happen.
Right.
Like reserved instances or something like that at AWS.
Right.
HST is already doing some of their process of reprocessing in the cloud.
That's another point is we get the data down from the observatories once and we process it once,
put it in our archive, and then we reprocess it again and again as the calibration algorithms
improve, as software bugs are found, and as reference data, it's particularly calibration
reference data, special data that's used to remove those instrumental signatures that
Megan was talking about.
As all that supplemental data and algorithms improve, you rerun the data again and again and
you need the computational capacity to do that while data is still coming down from the telescope
because your archive is getting bigger all the time.
So you've got a bigger crank to turn to get everything up to the best possible product it
could be.
That is pretty fascinating.
I hadn't really thought about that you would have to reprocess the data, but sure.
It drives all our designs because we reprocess the data tens of more times than that very
first time it hits the ground.
Sure.
What does the compute stuff look like for you all?
Are you using GPUs?
Are you using some of the NumPy, SciPy, AstroPy stack to do this?
Those are definitely involved, yeah.
Yeah.
So GPUs, I don't think we have an excessive amount of GPUs.
Probably those are more in the post-processing parts of the software.
But those other things you mentioned, most definitely.
And we actually are heavy contributors to those packages as well.
Fantastic.
We do a lot to provide back to the community the software that we're creating, especially
our external data analysis, post-processing analysis software, so that it can be used by
the rest of the community.
Yeah.
Samapriya asks, what can a user at home do with the data?
Or do you need these huge clusters, compute clusters, to work on them?
There are no books?
Yeah.
So if people are out there listening, I suspect there are some astronomers who have an expertise
in this, but there's probably a lot of people who are just fans of space and might want to
play with this.
So any data that's public that you can access in our archive, you can download and you can
analyze it.
You can install the science calibration software.
So the stuff that takes the data that we've already prepared for you and does further analysis
on it, we have visualization tools you can install.
We have many different things that scientists or even non-scientists might want to play with
to look at the data.
That's all possible.
I do that with Hubble data all the time on my laptop and my laptop just has 16 gigabytes of
RAM.
And now Hubble data is fairly small compared to the machines we were running on.
Yeah, I bet when it first, how old is Hubble?
20 years?
30.
Yeah, 30-year-old computers probably thought that data wasn't small.
Yeah.
So we've gone from terminal services to desktops and laptops and back to terminal services eventually
in the near future because of the size of the data.
Yeah.
So do you have notebook servers that are running close to the data that then you can log into
and play with?
Or what's that look like?
So we do at different levels.
You're talking about Jupyter Notebooks, Jupyter Lab, that type of thing?
Yeah.
So that does exist.
We've been playing around with science platforms in the cloud to give people access to not only
the software, but the data in a very easy way.
And I think Jupyter Lab makes that really, really effective for the tools that we can provide
to people.
Yeah.
But you can also run it yourself on your own local machines.
Sure.
As the data gets bigger and bigger, part of the cost and latency is just transferring it,
right?
So if you can run your compute close to it, you can save money by not transferring it and all
sorts of things, right?
Exactly.
Or reading it into memory for very, very large files.
As a system, the system itself needs to be very large to process the sheer volume of data
that we get and are constantly getting and reprocessing and storing and serving.
But for individual data pieces, it's still very possible for people to process it on their
own.
Sure.
Do you use things like Dask or any of these sort of Panda NumPy-like things that scale
out to larger data?
Yeah.
And it depends on the tool and what the purpose is that you're using.
Sure.
For sure.
Mike, got some thoughts on this before I move us along?
No, that's a really good summary of the picture.
Yeah.
And I think, I'm pretty sure at this point, all the public HST data is in the cloud.
I think it's all on AWS.
And I believe you can work with it there.
Yeah.
Especially if you've got research to do.
Yeah.
So one of the things that got my attention, besides someone, I think, sending me a message,
hey, you should talk to the JWST folks, is you have over at, on GitHub, you have the Space
Telescope Science Institute, where you've got all kinds of various things that people can
go play with, right?
Maybe tell us a bit about some of the highlights over there.
The one that I ran across is just JWST.
Yeah.
Which is, it describes itself as the Python Library for Science Observations from the JWST.
Yeah.
So this is the, what we call the science calibration package for JWST.
The software that lives here is able to do the detector calibration that we talked about
and image combination and everything else that we need to do to create the standard products
we've agreed to create for the mission.
That's all contained in this package.
And this package gets installed in our backend systems to be run as we're processing the data.
And it's ready to be processed at this level.
So this is what users would install if you wanted to reprocess or do higher level analysis,
the JWST data for the different instruments.
You spoke about the reprocessing and the reanalyzing.
So you would install this.
And if you had an idea on how to maybe do different noise reduction or other processing,
this is what you use.
Exactly.
We performed some base calibration to put the data in the archive and to make it somewhat
usable.
But most high level scientists are doing their own recalibration and they're tuning the data
for what they're trying to get out of it.
Especially if they're working at the margins of noise and other things where they really have
to work with the data to get out of it to fit their science needs.
So a lot of this is the byproduct of this proposal process because we don't know where
the science is.
It's going to come through.
We try to provide the best generic processing for all the data.
Right.
It's pretty neat that this is just here on GitHub.
That's cool.
Yeah.
I suspect when Hubble came out, it was not like, well, here's the open source thing and
here's how you contribute back in the same way.
Right.
I'm sure it was shared to some degree, but the openness of science and really the computational
bits of science over on GitHub is pretty amazing.
It's a lot of fun.
I think we started using GitHub when it first came out.
We were, especially during Hubble, using subversion and even older version control systems.
CVS or something dreadful like that.
CVS, RCS, even.
Whatever we could use.
Yeah.
They were run on internal systems and managed on internal web pages.
So when GitHub came out, it was really nice to be able to share our software, not only with
astronomers in the larger community, but with other missions that we interact with and to
be able to talk to them about how we develop and accept changes and improvements into the
software.
Yeah.
You see right here, there's a 541 issues and 20 PRs that are open, but 3,462 that are closed.
Yeah.
And that's pretty amazing.
Yeah.
That's what we do a lot of work.
And JWST is a new mission now.
Yeah.
Awesome.
So another thing that I ran across that looks interesting is the web PSF, which is a simulation
tool, right?
Maybe tell people about this.
So web is obviously the telescope.
PSF are point spread functions.
This is the statistical pattern that light falling on the detector from a star would make.
And you can predict what that pattern is going to be based on the optics that are in your
telescope.
And so this piece of software takes that understanding of the optics in the telescope and how light
gets transmitted through those optics, including through different wavelengths, and create simulated
images of what we might be able to see.
This allows us to not only predict how the telescope is going to perform in different ways, but develop
our software, develop the algorithms that we use to do pull out stars and stuff from images.
Yeah.
Very neat.
I suspect if people didn't have access to the telescope and they wanted to play around
with some stuff, maybe they could use this.
Yeah, they could.
There's other simulation tools that are out there that will simulate full astronomical scenes
as well.
So not just individual stars, but galaxies and the combination of the two.
Do you have something you can point people at?
I think I'd have to send you a link.
Yeah, we'll put it in the show notes.
Yeah.
Okay.
So people can get to it.
That's great.
Let's do that.
Yeah.
Awesome.
Another thing I ran across looking at all this stuff is this place called Astro Conda.
And there's a whole bunch of stuff, just tons of libraries in here.
It looks like there's a lot of neat things like, for example, working with the ASDF file format,
which I suspect is something that you all provide a lot of.
Yeah.
And so on.
So we developed that format.
We wrote that format.
The primary interpreter is in Python.
So a little bit of astronomy history.
Astronomy for a very long time has used a file format called FITS, Flexible Image Transport
System.
It started around the time data was being saved on tapes, a tape store.
You might want to optimize for different things if it's going on tape and SSD.
Right.
And so it's been in the community a long time.
And a lot of community tools are based on it, accessing it.
It was a big part of this other thing in the astronomy community called IRAF, which was
a common software package.
It actually had its own virtual operating system and command line languages that did the reduction
for us.
One of the things that JWST wrote about is we needed to be able to handle those complex
optical path descriptions for how the light from a star you're observing gets onto the
detector and how you translate those positions back and forth.
So where's telescope pointed?
Where is this light as it's moving around?
And how can I tell at this pixel what star that relates to in the sky?
Yeah, it seems very non-trivial because you've got all these different hexagonal pieces that
are independently adjustable and you've got to sort of reassemble that into a continuous
thing, right?
So that's part of it.
And even larger part is the number of optics that are in that chain and then the optics
inside each of the instruments.
And some of them are spectroscopic instruments that divide light into its constituent wavelengths.
And those wavelengths have different travel paths and will fall on the detector in different
places in mathematically predictable ways, but not always simple mathematically predictable
ways.
And so saving that information was really difficult in fits.
And we developed this new format that will allow us to save analytical models into the
data itself that can then be opened up by the users and very easily used to understand the
relationship between the stars and the pixels that they are looking at and the stars in the
sky.
And so we started JWST with that and it actually gets packaged into a fits file, but in later
missions, we'll be using just as diff.
Yeah, that's really neat.
So lets you save more of just the raw data.
It gives us a really nice way of saving information we need to understand about the data along with
the data itself.
We'd also save the binary arrays.
It's actually, if you were to look at it, the text part of the format is YAML based on JSON
schema standard.
Yeah.
Oh, fantastic.
So looking through this AstroConda thing here, obviously there's stuff that's very focused
on astronomy like ASDF, but there's also other cool libraries like APTRS.
There's all these like little things.
So if I want to write something to a temp file or where's my user home or stuff like that,
right?
You can ask questions like that of this APTRS thing.
Yeah, that's interesting.
I actually, I haven't looked at APTRS, but it must be being used by one of our other sub
packages and somebody wrote it, wrote it for a good purpose.
This AstroConda site that you're looking at was, you know, this repackaging of tools that
are written in Python, often with C extensions that can be used by astronomers in the community
to do what they need to do to look at the data, calibrate the data.
And so this AstroConda channel is a Conda channel that allows us to organize that information
and deliver it to users who are using Conda environments.
Nice.
Or virtual environments.
Yeah.
You can say something like install this channel, everything in this channel, and then you'll
basically be able to do most of the work that we're talking about or something like that.
Right.
And so most of these are now available also separately on CondaForge and PyPy.
So often people will install from there too.
Sure.
Yeah.
So we've got, let's see, ASTEval, a safe, minimalistic, evaluated for Python.
That's pretty cool.
You've got mysterious ones like CubeTools, which just refuse to identify themselves.
That's actually for 3D images.
So we stack things up.
Yeah, cool.
Anyway, I'll put the link to this in the show notes so people can look around.
It's just interesting to see all the stuff that you were bringing together here.
You've got the STSI version.
That's, you know, a meta package for Conda that will install the individual things that
go together.
Yeah, of course.
Of course.
All right.
This JWCS one sounds pretty interesting.
One of the challenges with the telescopes, I'm sure, is, you know, things orbit around other
things which are orbiting around other things, you know, around the sun, which is around through
the galaxy and whatnot.
Right.
So figuring out where you're pointing is probably pretty tricky.
Is that what this library does?
So when I was talking about being able to understand the light and where it is in the sky and on
the detector, this is what we're saving in the ASDIF file.
These GWCS representations, generalized world coordinate system.
And that's a mouthful.
World coordinate systems are what astronomers use to relate, you know, an undistorted scene
on the sky to what you have on the detector.
And it changes depending on what the telescope optics are.
But what GWCS provides is layered on top of astropy modeling, which allows you to string
together mathematical models to translate coordinates between two different systems.
So we use this for translating perfect sky coordinates to detector coordinates and intermediate
systems as well.
And one of the benefits to that is sometimes there are effects that happen in the detector
that should be corrected at different stages along the way.
And you can insert those corrections in this pipeline of models.
It makes sense to correct in this coordinate system, potentially, rather than at different
levels.
Something like that.
I see.
Right.
Yeah.
Pretty fascinating.
It sounds complicated.
It's cool.
Yeah.
It's cool.
It is definitely cool.
It's built on a lot, you know, on other open source code that is useful for more things
than just astronomy.
Right.
Modeling is useful for everything in science.
Fitting is useful for everything.
So it's cool that we can, you know, help provide tools like that to the community.
Yeah, for sure.
What's the machine learning story around the telescopes and the data?
Are you all doing anything with that?
Any AI stuff?
Avery, you want to take it?
So I'll talk about, you can pipe up Mike for the HST stuff if you want.
I'm not familiar with that aspect.
I know.
So, yeah, obviously we have data science groups at the Institute that are doing a lot
of machine learning.
Machine learning can be applied to things like the catalogs of objects that astronomers scrutinize
details about what these things are that are confirmed that can be used to build up information
about unknown images.
Machine learning for processing.
We've started doing some of that for the HST processing in order to optimize scheduling,
time, spreading the data out, understanding if there are certain metadata keywords, like
what Mike was talking about before, that we know will affect the processing in certain
ways.
We can detect that early and make up for it.
Interesting.
How much of a challenge is an optimization problem of who gets time when?
So this person wants to look here and do this, then that person is going to look over there.
But if there's somebody that wants to look in the middle, maybe you could save some fuel
by turning a heart way, letting them do their job, like skip ahead in line and then keep moving.
It's a great point.
It's not only fuel, it's you don't want to move your mechanisms more often than you have
to.
So you don't want to flip the filter wheel three positions left, 10 positions right,
when you could have done that in a more economic way and save the wear and tear on your system.
So there's a lot of optimization that goes into the planning and scheduling system.
And of course, with astronomy, there's visibility.
You've got a certain targets are not visible, not visible at all times of the year, just depending
on where they are relative to the sun.
Right.
You can't turn around and look right past the sun because it'll...
Oh no.
JDBC especially cannot look back.
Even in the software, there are defined regions of avoidance that we are not allowed to move
the telescope.
And so we have planning and scheduling systems that know what these things are, that know
the range of places that this telescope proposal approval community has decided to point the
telescope.
And it figures out what is the most optimal way to organize those observations to get them
to the astronomers as fast as possible.
I see.
Towards the end of our time together.
What other things are you doing with Python you think people find interesting that maybe
I haven't asked you about yet?
Or did I cover everything?
We covered a lot of graph.
Yeah.
There's a lot of nuts and bolts that the data processing side has to do.
You know, we interface with a lot of databases.
So we need database interface packages that talk to Microsoft SQL Server and SQLite database
files and things like that.
As Megan said, we do a lot of parsing.
So we're JSON parsing and XML parsing.
And so all those packages come into play.
And then there's good old-fashioned bit busting where we've got to get into the telemetry binary
files and bust out the sections of bits that are the data from the wrappers that come down
that let us make sure we got the right data.
Figure it out.
Yeah.
Exactly.
So various packages across the Python scheme help us.
And there are a lot of external community packages that help us as well.
And then there's also all the documentation that has to be done for every user, especially
for our externally delivered packages of Sphinx.
Okay.
And code documentation.
We have a lot of our stuff on Read the Docs.
A lot of our infrastructure for testing.
I just had the folks on from Myst and have to do a better search to get something other than
a video game.
But the Myst project, do you still do all your stuff in restructured text?
Or are you doing any of the markdown things with Myst?
I'm not doing anything with Myst.
I have done a lot of restructured tests and pure LaTeX.
And Sphinx helps with those two things, too.
A lot of the scientists themselves just write pure LaTeX.
They just write all their papers in pure LaTeX.
And the symbols for it are so crazy.
It's so many.
Yeah.
But what comes out of it is really remarkable.
So, yeah, it's worth it.
I mean, it's really pretty.
I remember being introduced to it even as an undergrad in the 90s.
And it was like, this actually looks much cooler than Word.
Yeah.
Absolutely.
Yeah.
When I was in grad school, I did some of my homework in LaTeX.
But I haven't touched it for many, many years.
Not anything practical.
Yeah.
They sell a lot of the journals and a lot of the astronomy conferences expect you to turn in
posters and papers written in LaTeX that conform to their standards.
Yeah.
Absolutely.
All right.
One final question I want to ask you about.
And Megan, you said you were working on this.
It's the Nancy Grace Roman Space Telescope.
Yeah.
We haven't even really got the web telescope fully online.
And you all are working on this next one.
Yeah.
Give us an elevator pitch for this so people can be excited.
And what's the time frame?
So Nancy Grace Roman is really cool.
It is also going to go out to L2 where JWST is sitting in part because it's an infrared telescope
as well.
It's focused in near infrared.
So more similar.
And the web one might get lonely.
So it needs a friend.
Yeah.
I mean, there are some other telescopes out there too.
But yes, we need more friends.
And so it is about, the mirror is about the same size as Hubble.
But its optical prescription gives it a much wider field of view.
So 100 times the field of view of Hubble.
And it has way more detectors than pixels.
About 300 megapixels.
So there's 18 detectors.
And every time we take a picture, all those detectors are going off.
So there's also a lot more data volume coming down that we get to process.
But a lot of cool things we can do.
We can reach the level of the Hubble deep field very fast.
We're going to cover about 50 times more space in the first five years of this mission
than Hubble has in 30 years.
So it's going to provide a lot of cool things for the community.
It's also a survey telescope.
So a lot of its time is dedicated to some surveys that want to be done to support the community.
Looking for exoplanets.
And they expect to find several thousand exoplanets during the first five years of the mission.
Investigating dark energy and the expansion of the universe and the physics behind that.
And so and other things that I'm sure astronomers will come up with.
One of the cool things is that it will be launched to be compatible and collaborative with JWST.
And LSST, one of the large ground-based missions.
And Euclid, one of the European-based missions.
So it's really cool to be in this era of astronomy where the missions can really be, you know,
working together to make cool new discoveries and take data.
That's fantastic.
I haven't even thought of them working together.
Quick question from Julian in the audience.
We'll wrap it up.
How many of the experiments are providing data through the pipelines immediately versus
that priority, like private period that we talked about?
So some of that is up to the scientists.
The scientists can choose when they submit their proposal to make the data public immediately.
As soon as we get it, we process it, it's in the archive and it's there.
That's very, very fast.
One of the standards for Hubble is there's typically a year that the scientists have to look at the
data exclusively with their group and do the science they want to do.
And then it'll be released.
But I think that there are also cases of longer than a year.
And wasn't Roman going to...
Roman has...
Yeah.
Roman has no proprietary period.
The data will all be public immediately and we'll be serving data in the cloud and on
front.
Wow.
So no dragging your feet if you're trying to make a discovery and want to get credit for
it.
No, no.
Yeah.
No scooping other people either.
You got to be on the ball.
That's right.
Okay.
So I think we got to leave it there, but it's really fascinating to see the ways that
Python and the data science tools are connecting us with space and these discoveries.
So thanks for sharing those.
Yeah.
Thanks for having us.
You're quite welcome.
Yeah.
You bet.
Now, before you get out of here, you got to answer the final two questions, but there's
a couple of you.
So just maybe lightning around.
So if you're going to write some Python code, what editor would you use these days?
I'm old school.
I'm a VI editor.
Right on.
Yeah.
I use VI, especially if I'm logging into servers and stuff.
I'm doing something quick.
If I'm doing a more complicated development, I usually use Sublime.
Okay.
Fantastic.
But in the past, I've used PyCharm and other ones.
Sure.
And how about a notable PyPI package?
Some library you came across recently and you're like, oh, this is so cool.
People should know about this.
I would recommend the Condor package.
If you've got to do any kind of distributed data processing, you should really know what
Condor is providing.
So I highly recommend exploring that.
Fantastic.
Megan?
I know we've talked about this.
I was so excited to see PyLab come out because it provides us, not PyLab, I'm sorry, JupyterLab.
It provides us with so many opportunities to get the data and the analysis to our scientists in the easiest way possible and allows them flexibility to work on it with their colleagues and produce really good science.
But from the other side, I actually saw recently this package called Silly, which just produces random bits of data you can use for tests with all sorts of entertaining things.
Yeah.
Silly.
I think you can even have it emit like Chuck Norris quotes and stuff like that, which can make it, you know, oh, no, that's PyJokes.
That was the other one I've heard recently, PyJokes.
Oh, I love PyJokes.
You can have it.
Yes.
I love Chuck Norris.
Yeah.
He only makes programming better.
He does.
And so silly is like faker, but silly.
It's silly.
I love it.
All right.
Cool.
Well, thank you both for being here.
If people want to get started with some of the JWST data or some of the libraries, you know, what would you say?
Go to our archive.
Yeah.
Archive.stsei.edu.
And as soon as the JWST data is coming through that they can look at, the public available data will be there.
Yeah.
And there's tools already there.
You can see, you know, the images, what they look like.
You can play with them a little bit.
You don't even have to know astronomy.
They have both the FITS formats that make them talk about from scientists.
And they have plain old JPEG preview images for folks to just browse and get a quick look at the sky.
Okay.
Fantastic.
All right.
Well, Megan and Mike, thank you so much for being here.
It's been great to chat JWST and space in general with you.
Yeah.
Thank you so much.
It was fun.
Take care.
Yeah.
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.
Datadog gives you visibility into the whole system running your code.
Visit talkpython.fm/datadog and see what you've been missing.
We'll throw in a free t-shirt with your free trial.
For over a dozen years, the Stack Overflow podcast has been exploring what it means to be a developer
and how the art and practice of software programming is changing the world.
Join them on that adventure at talkpython.fm/stackoverflow.
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 see you next time.