Just to set expectations, this is a sort of 101 level talk, okay? We're not going to go super deep into some of the patterns, we're not going to go super deep into some of the config, but hopefully you walk away with a good understanding of resilience, good understanding of reliability, and then you've got some tips and tricks that you can use with InkaD and with MSRI Ingress as well. And also a good understanding of what each of these things actually brings to the table, what rate limits can accomplish, what retries accomplish, et cetera, et cetera. Perfect. I'm Daniel. This is Flynn. We have worked together for five plus years. There were different companies and communities and so forth, very active in the open source community. We'd love to get involved in the Twitters. You can jump on our respective slacks, engage with us as well. Feel free to come up just at the end of the talk, but don't worry, you can always engage with us online as well. I'm always happy to chat afterwards. It's also worth pointing out for those of you who might know me from the past, that at buoyant, that is not a typo. I am at buoyant now. Not an ambassador of mine. Fantastic. So resilience. I always like to think about the, you know, why are we doing this stuff, right? I'm a technologist, you know, Java programmer by heart, by background. But I always like to think, why are we thinking about a thing? Why should we care about reliability? Why should we care about resilience, right? The user wants that reliable end-to-end experience, but they don't really want to know about the details, right? They just want the web app to work. They want to get a good user experience, right? You've got to handle north-south and east-west traffic when you're dealing with microservices. Back in my Java monolith days, north-south, traffic coming from the user to the monolith, happy days, right? As we split up to microservices, I started to get Ruby, Bit of Go, all these other things, suddenly I was implementing libraries to manage all the comms between the services. We've pulled that out. Things like observability, security, and resilience within the application now can be done via a service mesh, east-west. So I've got to think now, north-south, east-west, as we'll demonstrate, as Flynn will demonstrate, the patterns do differ, whether you're at the edge or within the mesh. So some little gotchas, little takeaways will go through there. And despite we're hearing at the conference, DevOps is not dead, right? And self-service is required is my pitch, right? And as a developer, I've been an operator, too, right? But I want to be able to do my work without interacting with unnecessary tickets, you know, Jira, all this kind of stuff, right? I just want to do my work, basically, whether I'm DevOps. Probably also worth pointing out that north-south and east-west have different patterns, but they are all required. You don't get to just go, oh, I've got resilience up on the north-south level, I'll just ignore east-west. That does not work. You have to think about it all the way through. Perfect, seven, perfect, seven. If you have not bumped in this book by Mike Nygaard, it is amazing. Check it out, Pragmatic Programmers. It goes into resilience patterns like our standard design patterns, right? Second edition of the book is out now. I learned so much from the first edition. It was, like, 10 years ago. And it's been updated with microservices, with cloud, in mind, although it is a technology agnostic book. It goes through retries, timeouts, rate limits, which we're going to cover today, sorry, with the MSRI Ingress and with Linkerd. It also goes through things like bulkheads. If you think in the Kubernetes land, that's like your quotas, your resource quotas, right? You don't want things overwhelming or consuming too many resources. Circuit breakers, you can do, like, in the mesh. You can do, in terms of, like, say, Envoy, I'll do a lot of work on Envoy. There is a mesh, sort of, or proxy-level circuit-breaking. And if you're from the Java world, and I'm sure other worlds as well, there's application-level circuit-breaking. Things like histricks from the Netflix stack. Spring have got a very similar pattern. We're not going to cover bulkheads and circuit breakers today, but, like Flynn said, they are an important thing in the toolbox. This is kind of a 101 talk, but do bear in mind there's other patterns out there. Excellent. Quick intro to MSRI Ingress. It is an open-source CNCF project, incubation-level. If you haven't heard of it, do check out the, you know, the website, the GitHub site. Pop along with Active Slack channel as well. It's all about getting your user traffic into your back-end services. It is an edge gateway, API gateway. Call it what you will. But the main thing is about getting that user traffic into the back-end. Why is it an option thing? You have been coding on it for, since inception, you were the lead engineer, right? Since 2017. Yeah, so it's battle-tested, right? That's one of the things, like, you know, there's many sort of ingressers out there, but this is battle-tested. It's used massive-scale at various different companies. It's a convoy. And we've wrapped that on top with the north-south use case in mind. If you think about the primary role of an ingress, of an API gateway, it is literally mapping from, we've got Jane in this sample, coked to a relevant back-end service, right? We've also got Mark here, going through to the back-end service. From a security perspective, we might want to stop that. We might have some auth in place, right? To stop that happening. Or the X might actually represent something breaking within the application, right? And that's where you need observability, rate-limiting, resilience, app development focus. We're mainly focusing on the middle two today, the rate-limiting and the resilience with the app development sort of mindset as well. But this is the role of an ingress. You're getting that user traffic front to back. In terms of configurations, this, you know, if you configured any kind of proxy before, any kind of API gateway, this should not be a big sort of change for you. This is our custom resource, mapping route back-end service. You can also go fancy. You can do canarying with weights, 10% of traffic. You can also add timeouts, which we're going to cover, right? And you can go even deeper with labels, which we'll use for rate-limiting, which I'll explain a bit later. You also need to set up things like the listener, right? Listing to ports. You're going to be setting up the host, probably some TLS and so forth as well. And of course, you want to set up the rate-limit service, which we'll walk you through later. And then notice is by a Kubernetes YAML, custom resources, right? Whatever your pipeline is, GitOps, or CI pipeline, CD pipeline, you can push your, like, deployments, your services down that. You can push this config down that as well, which is what I love about this kind of, you know, both from the Lincardee and from the Emissary's perspective, it's Kubernetes native, which is great. Just don't even think about it, right? But there is different personas at work here. Jane are DevOps persona You can split the workloads, right? And the operator sets the guardrails, sets the defaults, and then me as a developer, I go in and do my day-to-day work without needing to constantly bug them. So think about this, you know, there's often, like, be it security, be it observability, be it in our case resilience, the two personas work in hand-in-hand, but there's often different ways of configuring the tools, which we'll show a bit today as well. Think of that, Brooklyn, hand over to you. It's always interesting to hear, but it's not one rather than me doing that one. It's nice job. So this is the Lincardee shock and awe slide. Lots of logos and numbers and things like that. This is the real takeaway. Lincardee is a service mesh. It's all about mediating, monitoring, and adapting the east-west traffic from service to service. Lincardee's purpose in life is to give you what you need to create highly secure, reliable, observable, cloud-native applications, and to make those tools available free of charge. All of the logos back there thought that this was a good idea. All of the people starring the GitHub repo thought that was a good idea. I'd also like to point out we are currently the only CNCF graduated service mesh where that means that we are considered as mature as Kubernetes itself is. Emissary Ingris and Lincardee work out really nicely together. From Lincardee's perspective, Emissary is just another workload in the mesh. From Emissary's perspective, Lincardee is just another chunk of the Kubernetes networking layer. So you can literally just stick the two of them in the same cluster and they start working together, which is really lovely. I think... Oh, yes, sorry. I should point out. The way Lincardee works is by injecting these proxies next to each of the services and then having it... arranging things so that Kubernetes will route all of the traffic service to service through the proxies. There's also a control plane that keeps track of what the proxies are supposed to be doing. And that's really kind of all there is to it. I think you were going to talk about the demo architecture. So we'll now dive into some code. Flynn's going to be doing some live coding, so I hope the demo gods are with us. But just to set this up, this is the very simple architecture we've set up just to provide a realistic kind of use case, right? We have our faces gooey Actually, let me back up. Apologies. Just in terms of... The smiley service is responsible for sending back smileys, okay? Deep in our core graph, the color service is responsible for sending back colors. The face service aggregates these together. So you get green smiley face, right? When everything is working well, that's what we get. In theory, we should see lots of this in the browser when we do the demo. And then going back in again, you imagine we're calling through our faces gooey, it's a single page web app, through MSRI, into the back end, and you'll notice then there's lots of lovely linkies, our lobster from Linkadee, acting as a sidecar next to the services. That's the service mesh part. I don't think it's back to you. This is what you should always see when we're running this demo. Lots and lots of smiley faces on a green background. This is not what we're going to see at the start. Let me just be clear about that. There are a lot of different things that you might see. The cursing face when the smiley service is broken. You can see a gray background when the color service is broken. You can see the exploding head if the face's application, the face's service itself just has been completely overwhelmed. You can see this sort of thing for timeouts. One of the things that was deeply fascinating was that we have three services and I legit even though I'm the one who wrote all three of these things and put the whole thing together, there were points where I had to use all of the tools, both on the emissary side and the Linkadee side to figure out what was going on in my own demo even with just three applications. This stuff gets very, very complex very quickly. Which is what we're going to look at now. Oh, yes, one other thing. The web app is actually willing to show the user old data if the services are responding. For our purposes in the demo you'll see that little counter ticking up when it has had something that's a little confusing but decided, it's okay, I can keep showing this data. It'll be all right. All right. Let's use the demo. I'm not actually going to show the installation of emissary and Linkadee and all that. We have a cluster running. It's actually, in this case, it's a K3D cluster running on this laptop. Could be anything, doesn't really matter. We've got our single page web app running here. We would like to see a grid of smiley faces on green backgrounds and you won't notice that we are not, in fact, seeing that. Places where you see the cell just vanish are because something just took way too long and the web app gave up. The red background is where we couldn't even talk to the face service. So I guess let's go ahead and get started here. The first thing we can do is we can see if we can get rid of that bit with the frowny face on the red background. We're going to do that by telling emissary to do retries automatically if an error comes back from the face service. So the lines in green there, we're adding a retry policy to the mapping for the face service. So that we're basically telling emissary if you get any 5xx response retry it. Only retry it once, but retry it now. Let's go ahead and apply that one. We are telling emissary to only retry once just because that makes it a little bit simpler to reason about what's going on. We don't necessarily expect that that will get rid of all of these errors because we only get one retry.  But you can already see from applying this we have a lot fewer of those simply by telling emissary go ahead and do the retry. Also notice we haven't changed anything at all in the application. All we have changed is a bit in our API gateway. So let's see if we can get rid of the cursing face from the smiley service. We'll do exactly the same thing. We'll tell emissary to do a retry. Any guesses to what should happen here? Anybody? All right. Let's do that differently. Raise your hand if you think this will work. Nobody. Okay. Raise your hand if you think it won't work. Uh-oh. Nobody's really committed at all. Let's find out. In point of fact it does not work. It has absolutely no effect. And the reason for this is the call from the face service to the smiley service and the way the app was put together, it doesn't go through emissary at all. It happens past emissary. Emissary has no ability to affect this. So instead, we will tell Linkerd to retry that. Things are a little bit different in terms of the configuration. On the emissary side, sorry about that, on the emissary side we had to tell it, retry in a 5xx and you get to do one retry and on the Linkerd side we just say, yeah, this is retryable. You can control this more. We don't need to in this case. That basically is telling Linkerd any of the 5xx's will retry. Linkerd has a concept of a retry budget where it will just keep retrying until you go over the retry budget. By default I believe that's 20%. As long as not more than 20% of the traffic is coming from retries, Linkerd will keep retrying. You can tune that, but often you don't really need to. Now we're getting as much smiley faces and no cursing. No cursing is good. We can repeat the same thing and see if we can make the grey colours go away. The answer is they go away from retrying things. You'll also notice every so often we still see that red background because again, emissary is only doing one retry. We could go through and play with a number of retries. We could tell emissary is okay to do two retries. We could tell it five, whatever. Some of them will probably always be able to sneak through a little bit and so that's a thing to be aware of.  So let's go through and do some timeouts here. We're going to do timeouts from the other direction. Retries we started at the top of the call graph and worked our way down just to demonstrate that you can do this the other direction with timeouts. And then work our way back up. The other thing that's worth pointing out here is adding timeouts is not really about protecting your services. Adding timeouts is about giving your client the ability to do something when it takes too long and making it easy for the client. It's giving your client some agency to decide what to do. In this particular case if the face service can't talk to the color service it'll start showing it as a pink background because it took too long. We also see that there are already fewer cells vanishing because now there's less stuff taking too long. We can do exactly the same thing for the smiley service where we'll see the sleeping face if things start taking too long and even at this point we don't really see any more of those cells just vanishing and staying vanished. We can of course do the same thing at the emissary layer so we can just tell emissary, hey whatever's going on deep in the call graph there, if it takes you too long to hear back from the face service just go and give up on that. And in this particular case this is where we'll start seeing those counters appear where everywhere there the GUI has decided I'm going to go ahead and I'm going to show some old data here that counter is really just there for demos. Did you also notice the one up there in the upper... sorry some of these where you'll see the sleeping face that's sort of grayed out that's where the client has just decided this is taking too long in general anyway. But the point here is that the client the web app now has the ability to decide what to do when things take too long rather than just stalling and giving the user something weird and confusing from the user's point of view. This gives us with rate limits and we will let Daniel talk about rate limiting. Yeah, we've got the code up on screen not there. So, well, alright, I'll say one more thing here. Imagine if you will that one of your developers has deployed something where suddenly your service gets a lot slower somewhere down on the call graph. So we've just done that we've just modified this deployment and you'll probably see a bunch of red pop up here as the deployment recycles but now it will start exploding if things get hammered too much. Like that. Perfect. And then it is the next bit of him for showing the rating. Yeah, go ahead. Super. So the rate limiting looks a little bit different than perhaps you might expect but the timeouts and the retries it's like pretty self-explanatory, correct? But with the way we've exposed the functionality in the rate limiting it's based on the original lift rate limiter. So lift is in the company. We all probably jump to lift to get here, right? The way they exposed their rate limiter was very much based on labels. The idea being you could apply a bunch of labels to a mapping that data then gets passed down to the rate limiter service that we created, or the risks about the box options too, and with that data being passed down through you can make rate limiting decisions. So I've got some quite basic examples here. I think I'll just use a generic key, right? Yeah. You can pass, well, by default properties such as the remote IP the source and destination a bunch of useful information gets passed down through and you can say hey, I want a rate limit based on this IP. I want a rate limit based on these headers being injected for example. Very customizable do advise you to check out the MSOI docs because it is quite rich and when I say rich, can mean complicated sometimes, right? But it's not when you take a pause and go through it and quite as perhaps obvious as what Flynn's already shown with the retries and the timeouts. See, this is why I'm making Daniel talk about the rate limit. Yes, thanks then. Appreciate it. Anytime. The good thing is, look, I've got a sample rate limit app I wrote in some Go. There is an old Java one I wrote back and it's still out there on the interwebs as well and we'll show the code at the end but we've put the link in there. Pop along to the repo. You can see I've actually used Honeycomb. Honeycomb.io's leaky bucket algorithm. So very simple Go service. There's an API, protobuf API you have to implement for the rate limiter service so I generated my stubs from that used Honeycomb's leaky bucket to I think it was 8 RPS in the end of Flynn we did, didn't we? Yes, and if you read carefully on the previous screen here, you would have noticed that the environment variable we set on the face service has it blow up at 8.5 requests per second so doing setting it rate limit at 8 per second should give us some relief. Fingers crossed. So everything is highly customizable you can look at the labels being passed in, you can look at the headers and make those rate limiting decisions and I'm happy to drop by the booth later on, happy to walk you through and some of the options there for the rate limiting. But without further ado let's now give this a try and we should see a lot less explosions. Now the nature of this, we have to go through and refresh all these cells so they're not going to vanish immediately but if we give it a few seconds we should see the exploding heads go away. That is always good when the general works, right? It's always nice. Fantastic. The last thing that we should point out here oh by the way, sorry, there are two last things we should point out. One is if we turn off the counters then that gives a better example of if you had an end user who was using an SPA like this this would be more the thing that they would see where, okay, every so often they'll get a delay but for the most part they're just going to see smiley faces on green backgrounds which is what they're supposed to see so we have here an application that's composed of honestly some pretty badly behaving microservices these are terrible but we've been able to use Emissary Ingress and LinkerD to mitigate some of the terribleness here and overall give the user an experience that can actually be pretty good without having to go mess with the code of the application and we did this in what, 10 minutes? Just going through and tweaking things obviously you're not actually going to fix this without fixing the application code which we will not show you here that's a little bit outside the scope of Emissary but the point here is that even before you fix the application code there's an enormous amount of stuff you can do to mitigate the effects of badly behaving code and give your users a better experience particularly on that note we talked earlier about the different personas I've definitely worked in an ops persona where it was hard to get some of the developers to engage and that's another problem that is DevOps to work on that kind of thing but the same time I had a limited set of tools available to me as a platform engineer as an operator and it got me 80% of the way there there was a couple of super old really janky heritage apps and I could protect them in a bubble somewhat to Flynn's point, clients then calling could interact for the most part with those as though they were reliable please do document these things right in terms of hereby dragons kind of thing and ideally fix it to Flynn's point but this super old service, no one went there we just couldn't fix it right so we protected it in a bubble with retries, rate limits and timeouts we got a set of tools in my toolbox then I went and checked the developers what can we do to actually make this service more reliable right and if anybody's curious these apps the services down in the mesh are actually hard coded to fail 20% of the time which is just got off in terms of terrible, terrible application and they're also hard coded to do things like something like half the time to respond so terrible metrics down there at the application level but we're still able to deliver a decent user experience just by messing with things in the API gateway and the service mesh so please do not take this as any endorsement of a 20% failure rate being acceptable or anything like that but yeah back to the slides for everything any file wrap up do we have more on the slides? yeah just a final bit of conclusion there we go, we do perfect so just coming back to the full circle hopefully you've taken away from this that users want the reliable software they don't necessarily care about the internal details that's our jobs right as developers as QA as platform engineers you do need to think about this end to end but you need to ideally start with the services but in reality you're probably going to be looking at communications like we've talked about you want to fix things if they're broken but it's a nice tool to have in your toolbox and at least cloud native communications the north, south, east, west think about the whole thing it's very tempting if you're really into your meshes just to try and solve everything in the mesh if you're really into API gateway just to solve everything there but something like emissary ingus and something like linkerd together hopefully you've seen that give you a lot more options there is a few dragons it's very easy to mess up some of the time-outs sometimes with time-outs at the edge versus time-outs in the mesh as well I'm happy to talk about that afterwards if anybody wants to know some of the dragons we ran into while we were doing this there were a lot of them but for the most part I really do like the combination of the two separate things, ingress gateway and the mesh gives me the options the combination is very powerful love it and the mix of retries, time-outs and rate limits does genuinely go a long way I've seen some folks get a bit too into the circuit breakers too early because they're kind of the hotness back a few years ago everyone was loving histricks and at the application level it gives you more options again we're at the wire level here we're at the service comms level but honestly retries, time-outs, rate limits I'm a big fan of keeping it simple and make sure your solution is developer-focused and self-service that's why build on the tools that are out there I've seen some folks try to hack all this into libraries and that can work but I'm a big fan of like some other folks have already done this stuff there's an open source project, there's a CNCF project contribute, get involved and contributions can be docs because we love contribution but it can be code as well so rather than do your own thing rather than try and push it in super ops focused or super dev focused think about that end-to-end experience, developer-focused, self-service and the CNCF tools are all about that Kubernetes, cloud-native is all about declarative, self-service config one thing we didn't put on this slide that occurs to me we probably should have is just another note about the fact that remember the app we were demonstrating is very very simple and shows some extremely complex behaviors as you start looking at how those different things interact with each other so we didn't really talk about it much in this slide, we didn't talk much about the observability and debugging part but there are a lot of tools to help with that as well and it can be very very helpful to think about this from the beginning of you developing your app rather than waiting until things are going wrong so yeah final slide, references there the main demo you can find oops we'll need to update the top link pay no attention to the top link update and then my rate limiting service is below as well which I moved into the ambassador labs repo, hopefully self-explanatory we've tried to document as good as we can but always happy to take questions on our Slack or 5 million on the CNCF Slack as well and we also have the docs for linkadee and the docs for msr ingress as well, do let us know how you get on with these things, we love feedback, we love PRs in the docs as well if you spot something that's a bit incorrect or not super obvious and we always both projects very much appreciate docs PRs there we go, now there's nothing to hide on the slide and I think if everyone's taking their pictures, I saw folks with a few cameras it was great, we have a few minutes five or so minutes for questions if anyone would like to check anything out I think it might come up be roving, I'll thank you or you know just wander up afterwards but always happy to take questions now so we saw your demo where you came to your initial values for some of these things and incident situation, is it appropriate to proactively change some of them initial values, sorry which ones for example, your time out that you initially came to 250 million, oh yeah I am not going to lie the time out values that we showed in this demo have gone through probably a dozen different iterations while Daniel and I played with things it took a while to find combinations that gave really good results and that's another case where the observability part plays a huge role in this one, where we'd go change something and then look at the demo and go, huh that's funny, that's not quite what we expected to happen and then we'd go through and poke around through emissaries logs and the linkardy dashboards and things like that and realize what was going on and then iterate and just keep going, so yeah 100% there's a very iterative process on all this stuff this is like watching a tennis match we genuinely are scouting a room any other questions at all if not oh perfect, yeah in the retry policies there's some way to do a back off so it doesn't retry immediately or an exponential back off I'm going to have to go look that up to be candid same as me if I remember right I believe that there is but I'm going to have to go look that up we kind of deliberately deliberately didn't want to get too deep into that for this one because we'd run out of time if we did excellent question though thank you and the folks that perhaps haven't bumped into this you've got microsavers and you're doing lots of retries and things, it's very easy to get what's called a thundering herd something we talked about showing and ended up deciding we didn't have time for if you look at the linkerdviz dashboard when the demo app is running in the first place I wonder if I can show a bit of that I need to go reset everything here so if you look at the viz dashboard it will show you how many requests per second are happening to a given service and when we start this off with this particular demo it hovers right around 8 per second there are 16 cells in each cell refreshes every 2 seconds as soon as you turn on retries that number goes to 9.6 because 20% of them immediately get retried because of the failure rate so yeah it is really interesting to watch how some of these effects or how some of these changes have differing effects on what happens to the services retries and rate limits and timeouts and such so if you increase the amount of load on your service not decrease it but again it gives your user a better experience and so overall it is a good trade off to make Mike Nagler's book that we put up it released it, it is a fantastic map perspective as well it talks about thundering her it talks about resonance in the application you have got to think about some of these things I have definitely worked on systems where retries have actually taken down the system because it overloaded and you get this thundering her so that is a good question good shout do check out that book it is fantastic to educate you about that Hello guys, thank you for the presentation I am wondering because when you look at the presentation like the focus you can clearly select it is towards the end user but I am wondering when it comes to service to service communication have you tried it if so what are the dos and the don'ts sorry what was the what was the question I am asking when it comes to service to service communication so what should I do or should I should not do what should you do or not do exactly I will prefix the conversation further answer by saying I always recommend thinking about the end to end definitely when I was doing platform work I was just like hey service to service it is really important but always think about that goal the end user and folks do timeouts and stuff in the service mesh that were completely ignored by Ingress because Ingress was too tight on the timeouts always think about end to end but probably a better answer in terms of service to service dos and don'ts actually I think your answer was pretty good nobody runs Kubernetes just for the sake of running Kubernetes everybody runs Kubernetes because there is something they want to accomplish for their end user and so starting out by thinking about how to play out for the end user is the critical bit I don't know that there are any hard and fast rules in terms of what to do for service to service the way that we've been approaching it as we were working through this is all about thinking about how it's supposed to look to the end user watching this web app and then you know okay well we know that this bit is slow what can we do about this bit down here wait a minute if we make this bit timeout like this we still have this problem that this bit behind it is too slow so maybe we can start there and focus on that bit right again it's very iterative it's a lot of watching and observing and tweaking but pretty much always starting out from the perspective of thinking about the end user is I think the way to go one final comment I had on that as well if something looks too complicated it probably is because I've definitely done that where I put all these things around the edge to protect my services and I was like you know what I think I should fix this service right ultimately again you know no amount of stuff you can do in the Ingress or the service mesh is going to 100% compensate for a service that's terrible like these are so ultimately you have to fix the service it's 30 seconds left so it's like a super fast question really quick question I guess we do thanks for the insights would be helpful to have some sort of tools to run or simulate traffic to be able to fix out the right mixture of those parameters you've been playing with and maybe we can through AI in the future to be able to adjust all those parameters automatically fantastic question and I reckon there's a whole talk we could do on the answer to that it's a great low testing synthetic monitoring definitely look at those kind of things great question we might unfortunately have to read chat afterwards so much room for tooling around all this we should have mentioned that we talked about experimentation we talked about iteration having a firm benchmarking situation is well worth investing in awesome I think we better wrap up we'll be around thank you very much for your time absolutely come find us if you need more


Welcome to Vettagetti, Iceland. We're going to take you on the journey of Icelandic local tomato producers. Yup, that's right! Here, we produce tomatoes even with the snow and freezing temperatures. Let's discover how. And welcome to the greenhouse of the Agricultural University of Iceland, where students are trained on all the skills needed to set up the next commercial greenhouse venture. My name is Gürri Helke-Döfters and I'm the head of the Department of Vocational Training and Continuing Education at the Agricultural University of Iceland. Typically we would grow food crops like tomatoes, cucumbers, salads and herbs, but also cut flowers and potted plants in greenhouses in Iceland. So our biggest challenge is possibly supplying the plants with enough light for them to be able to produce. We've got plenty of cold water and it's clean. We use the same water for watering the plants as we use for drinking. We have the geothermal energy to heat up the greenhouses. The electricity is produced with green energy, either hydropower or geothermal. And we also get CO2, which is like plant food. We get that from a local source. The tomatoes that we grow in greenhouses are slightly different from the ones that grow outdoors. The ones in the greenhouses, they tend to be quite thin and tall. They can grow up to eight, maybe ten metres during the ten months that they live. Now you might be wondering whether the tomatoes grown in greenhouses are as nutritious as the ones grown outdoors. And it's almost no difference between them. One of the main reasons why we're able to get a high yield when we grow tomatoes in greenhouses is that we use bees for pollination. But when we're using the bees we get something like 90-95% yield from plants, which is an enormous increase, if you think about it, from a farmer's point of view. It's also a good thing that we are not spraying with chemicals inside our greenhouse chambers because if we spray we kill the bees as well. So when we're using biological pest control, for example against aphids or other pests that might harm the plants, spider mites and such, if we spray we kill all the bad bugs, but we also kill the bees. So that's one of the reasons that the farmers are not spraying in the greenhouses in Iceland. So while we are looking at more technology or technologically complicated greenhouses on the one hand, on the other hand we will have traditional farmers using organic methods of producing food. So I think this will evolve hand-in-hand in the future.


Kansas' Ocha Agbaji is a throwback to what college basketball used to be, where players would withstand the test of time and hard work and gradually get better as their career progressed. Agbaji was not an elite recruit at a high school, but improved each year he was in college and made a whopping 103 three-point shots last season as a senior. He was six of seven from three-point range in the final four against Villanova. Agbaji projects as an NBA two-guard who can defend his position at the next level. He had four games last season with five or more made three-point shots. The comparison for Ocha Agbaji, think Desmond Bain.


All right, welcome back to the, the, uh, welcome back. I am tasked with reminding you that if you have finished trivia, please bring up your trivia sheet to our trivia czar up here. Thank you very much. And then we will begin the night with our first fabulous talk. I don't know how. Let's keep that enthusiasm. Let me introduce our fabulous first speaker in astronomy, underground at the University of Washington. He's asked that I introduce him by his full name. Please give a warm welcome to Key and Robert Lee Roy Cookin. Uh, can everyone hear me? Yeah? All right. How you guys doing tonight? Fantastic. Thanks for coming out on this slightly chilly day to, uh, learn about how silly and frivolous I am. So for those of you that don't know, uh, the name of this talk that I'm getting is based on the Untitled Goose Game, uh, 2020 or 2019 release on the Switch. Basically, for those who don't know, you play as a goose that wrecks havoc, uh, which felt appropriate to the chaos that's about to ensue. So, without any further ado, uh, my name is Key and Robert Lee Roy Cookin. I'm an undergraduate at UW. Uh, yeah, don't tell my mom. Actually, my mom's probably watching right now. Hi mom and grandma, maybe. Uh, whoop. Oh, oh, oh. Ooh, spoilers. Uh, yeah, I study massive stars, although I'm not going to talk about that much, because really, I'm here as a paragon of academic integrity. This is going to be a very serious talk, and you should treat it as such. I'm very, and I make normal decisions. So you're going to feel, these are going to be relatable decisions. And here's me, this is a screen cap of the game. So, let's get going. So, yeah, we want to talk about what is academic integrity, and as you might have seen, uh, it's not this, because if you look at Hasbro's website, all players draw seven letters, and if we look back, one, two, three, four, five, six, seven, eight, nine letters, perfect example. Uh, you can go to this website, although it didn't actually have the picture on there. I just needed to cite it to keep up with my theme. So, we're going to go, uh, this is what U-Dub considers to be academic misconduct. Uh, just, whoa, academic misconduct. So, can, uh, everyone who's ever done one of these, can you raise your hand, maybe in high school or college? I'm seeing some hands. Art, yeah, Thomas. Raise your hand, Thomas. Well, I fooled you. I'm a cop. I brought in, this is Frank. He's going to take you all to jail now.  Yeah, so we got plagiarism, cheating, falsification, a lot of standard stuff. Uh, one way that you don't get, uh, Frank to take you to jail is you want to do some citations. Hawk says the goose. If I don't say he says the goose, you might think that Hawk are my words. And we wouldn't want that. I wouldn't want to take credit for those beautiful words. Uh, so, we've got some examples. So, it gives credit for, for example, the force of gravity is proportional to mass. Newton really came up with that idea, so we want to give him credit. Uh, you can also, you know, give some more weight behind your arguments if you're citing someone who's an expert such as you must go fast, quote, Sonic 2020. Uh, or, uh, make sure that you don't have to explain anything. For example, if I'm talking about special relativity, that's complicated. And if I don't, if that's not the topic of my paper, I don't really want to go into it too much. So, uh, we're going to just cite Einstein and say, go read his stuff. He explains it better. These are all equal citations in the eyes of the law. In the eyes of the break. Uh, so you cite, when you're looking for citations, really you're just reading a lot. And you just repaper after paper after paper. You do a lot of keyword searches. And eventually you find something that, uh, you want to put into your paper. So you add one sentence, and then you repeat until you have just so, so many. It can take a long time. Again, uh, yeah. Oh, it went in slow-mo. That's fun. Yeah, it sort of feels like that sometimes. It can sometimes be a bit of a slog. It can be kind of tedious. But, you know, I don't think it has to be. Academic integrity is important, and it should feel important when you're doing it. It shouldn't just be something that you feel forced to do. Uh, here's some examples of really interesting things you can find in papers. This is a math paper. Uh, and you see here, they quote T.J. Kaczynski. Uh, he's better known for other work. If you don't know who T.J. Kaczynski is, he is the unabomber. And so, you know, you do have, the paper had to cite him, because otherwise they'd be stealing his work. But, uh, I think they worked it in well. He was better known for other work. Uh, and here's something exciting that my research advisor Emily Beck told me about today. This is a paper by, and that's not a lie. His name is Norbert, and I just thought that was fun. But this is a paper from 1987, and they were talking about the observations they had taken. And I just want to take, take you through this really quick step by step. No data were taken at station D during the period 832-430. And what's the reason? It was due to the presence of a red racer snake. That's the scientific name. Draped across the high tension wires. And you might want to close your ears right now if you don't want to hear about, uh, animals doing, just getting zapped with 33,000 volts. That was serving the station. But, critically, even though the snake, or rather a three foot section of its remains, was caught in the act of, uh, causing an arc between the transmission lines, we do not consider it responsible for the loss of data. No, rather, we blame the incompetence, and I think this is me. That's just too much, Norbert. The incompetence of a red-tailed hawk who had apparently built a defective mess that fell off the top of the nearby transmission tower, casting the nestlings to the ground, along with their entire food reserve, and they didn't have to include this, they could have stopped here. But they did list the different varieties of rat, the pack rat, a kangaroo rat, several snakes, with the exception of the above mentioned snake, about a somewhat higher density. And they do feel it's necessary to say, no comparable loss of data occurred at other end of the day. This was a one-off, believe it or not. Uh, this is the type of complete honesty and utter integrity you want in any paper that you are right. So, uh, yeah, science can be fun, right? That's fun. I think that's fun. I make normal decisions. But let's talk about what I, what I've done.  So, I study, uh, massive stars. One of those stars is P. Cygni in the constellation Cygnus. And so, part of the, uh, paper writing process, I'm writing an introduction, and I want to introduce the readers to what P. Cygni is. You don't need to know. It's too, it's too much for this. Because what I really wanted to do is I wanted to find the first recorded, uh, the first recording of it being discovered. Because actually, unlike a lot of stars, P. Cygni was too dim to be seen in before 1600. But then suddenly in 1600, it got really bright and was discovered for the very first time. Uh, even before, this is about the time that telescopes were being invented, but there, people weren't using telescopes looking for stars. Uh, and I actually was inspired by this YouTube video by UW's own James Davenport, uh, for the love of old books and older science. Is James here? Is Jim Davenport here tonight? He gives talks here, but, uh, he talks about how there's like, there can be a little bit of a game that academics like to play where you try and get just the oldest citation that you can. Because it feels cool to be able to back up what you're saying with, say, uh, yeah, well, this is also what Tommy said a few thousand years ago. It makes you feel good when, uh, you're trying, when you're trying to, trying to just stave off the imposter syndrome. So, uh, it turns out, actually, the P. Cygni was first, the first recording of it being discovered was on a globe by villain Jan Zun Blau, I call him Willie. Uh, and so he made this globe. He was a student of Tycho Brahe, who's a famous astronomer, and he was Europe's best globe maker in the 1600s for whatever that's worth, but he made this globe of the sky and there's legends that on one of those globes, he wrote an inscription talking about how he, how he found a new star in the constellation Cygnus. But none of the papers that talk about that globe ever cite any sources. So I'm sitting here, I'm thinking, I want to know more about this globe and can I trust these authors? They obviously aren't living up to my high expectations of academic integrity, and I will send Frank to take them to jail. And so I wanted to find out more. And so the hunt begins. And so, what they said is that, uh, most of the papers said it was in a Prague museum, which isn't helpful considering that there are 80 museums in Prague. I also appreciate that I can just Google how many museums are in Prague and I can get the answer. It turns out none of these museums are of globes. I checked. I checked really hard. I spent maybe a week, two weeks, just this nine at the back of my, just in the back of my mind. I was looking up, you know, I need to figure out who I can call at these museums to ask about this obscure 16th century globe. It turns out UW has a Czech department. I was getting ready to ask some Czech professor if they knew anything about a globe and a Prague museum air quotes. But, eventually, I think this was weeks of work. Actually, Kajen, raise your hand, actually cracked the code. And it turned out that it was actually this place. This is a castle in Sweden called Skåklöster Castle. It's about an hour train ride north of Stockholm. And so they claimed to have this globe here. So I thought, okay, okay, I found it. I could put that in my paper. But then I thought, is it really there? How do I know? How do I know that it's there? So I met my best friend in the whole world, Inger. I emailed them and basically said, hi, I'm a very professional and very serious astronomer. Can you tell me where this globe is? And I got to do the very fun activity of coming through a meeting. Everyone that works on Master Stars, we all get together and say, oh, I made this plot, found out this new thing, gave this talk. And I got to say, oh, by the way, the castle emailed me back. And Inger told me, this is just the beginning. Thank you so much for your question about the globe and the collections of Skåklöster Castle. It's always interesting for us when objects in our collection is in focus, and that just warms my heart. Inger, just the kindest, most helpful person I've ever emailed, she sent me a picture, actually, of the globe and confirmed that it was there that the inscription talked about peace signy. Actually, Thomas helped me to translate the pseudo-Latin that it was written in. It seemed like Blau didn't know Latin that well. It was kind of mixed with Dutch. But, talked about that, figured out that it was there. And so, mission accomplished. Without a citation, it's going to go on the paper. I talked to Paul Scurdi who's told me that I could put that globe as a citation. That was good enough. So, short talk, I guess. But I don't know. There's still some doubt. I mean, we love Inger. We would never send Frank after Inger. But how do I really know that it's there? It's almost like, I don't know. There's really only one way to do it. I thought to myself, gosh darn, I'm going to have to do a globe trip. And so, started doing some research. This is where Scope Gloucester is. This is Stockholm, the capital of Sweden. Got Denmark, so you can imagine. Over here on the tarp is Russia coming around. And it's about 4,000 to 5,000 miles. And I thought, yeah, sure. Why not? Anything to keep my title as a paragon of academic integrity into it? Any cost. And so, I went to Sweden. I bought a plane ticket. I traveled hours. Did the terrible, terrible task of getting a lay of the land, seeing all the beautiful sights of Stockholm. It was really terrible. Then I went to, it's a beautiful country. To ridiculous. Took a train, Nord. And eventually I had to transfer to a bus. And I almost didn't make it. The bus that I had to take to the castle, it was on a different system than the transit card that I had. And the only person in the whole bus depot, this big open parking lot, was this just, just very old Swedish lady. And I didn't know what was happening. I walked up to her and I asked in my very bad Swedish, uh, Talurdu, Angloske, which is, do you speak English? She said, no. Luckily I did have a police, I hired a police sketch artist to do this, to do this portrait of her, so I would never forget her face. But eventually I figured it out. Just with the help of this lady, we both laughed at me. She laughed at me first. But I, you know, it was, it was in, it was in just, I guess. We, but I figured it out. I found the bus.  I finally got here. This is a picture I took with my own camera. Uh, this is the castle. It was beautiful. Out in the middle of just nowhere. Uh, in this, right next to this lake, this ancient castle, uh, is a pastoral Sweden. And I found it. I found the globe. Here it is. Well, never doubt my integrity. We, I found it. I stood there probably for an hour and just sort of stood there. Like I was a guide, like maybe some of the, these like, a bunch of German tourists were going to ask me questions about the globe, maybe. I'm like, yeah, I know everything about this. Here's this inscription. This is what it says. It turns out they didn't think it was as cool as I did, but I had a great time. And I confirmed that it was there. And here's the inscription. Beautiful. Uh, here's, I actually now have this as a tattoo.  And here it is. The final, the final product, the subject of this paper, P. Signi, was discovered on August 18th, 1600. The Dutch cartographer, the glove maker and former student of Tycho Brachy, Wilhelm Jensen, but Willie, observed the nobastera in the heart of Cygnus. Wow, 1602. Bing bang, there it is.  The Chronicle was discovered on the inscription on the celestial globe, which he made in his Amsterdam workshop in 1602. And I did include the footnote, just because these two sentences weren't enough for me. I needed a third, the globe, as of the writing of this paper, because you never know.  I did the collections of Stoke-Loster Castle, Castle and Museum, north of Stockholm. And I even included a link so that, for posterity, people would know. People would always know. But wait! This is... That's not Stoke-Loster. I got this message from my research advisor, Emily Lebeck. Not but two weeks ago, she was in Rome, and she went into a library, and she said, wait, that globe looks familiar. And in fact, this is a willy. This is willy-blow from one year after. So I did find the original, but there's more out there. The story is... The story is still being written. Maybe there is somewhere in Prague, in, quote, a Prague museum, a third. There might be a fourth. Who knows? This was, of course, Europe's most prolific globe maker. Guess we'll have to find out some other time. I'll have to come back.  This is my life's work now, I think. It certainly feels like it, but thank you so much. Anyone have any questions? Any questions? Yeah, right here. Fantastic. The question was, how do you know that my globe, my globe, was the original? I choose to believe it. The one in Rome, it did say that that globe was made in 1603. If you remember, my mind was, we got it right here, 1602, so we're good, we're good on that one at least. There's other globes. I mean, I don't know. I choose to believe that it is so.  A thousand. So I do resent that question. Thank you. Any other questions? Nicole. The citation says 1602, but you say that it was discovered in 1600. Why is there a two-year gap there? Yeah, so the question is, if it was discovered and it became visible in 1600, August 18th of 1600, why is my citation from 1602 couldn't I trim it down a couple of years? Again, I choose to believe it. Really, I guess there weren't that many people writing about stars, that the other, the next closest reference to it is, in 1603, the Bayer Astronomical said, forget what it's called, there's just a bunch of maps of different constellations in the sky, and that's from 1603. There aren't a lot of writings about it that have survived, but everywhere in the literature, they were talking about this below, and even though they didn't cite it, and they are going to go to jail. But, I think it does, you know, Blau was a master of his work. I think he just took a long time to actually get this thing out. It's really beautiful, like they're in person, like the picture here, you can imagine it looks really big, but actually, the castle, the website, the globe, the picture of the globe that they have there, they have it photoshopped for some reason, so that it looks like it's the size of a room, and I was really confused by that, so I got there and I wasn't sure, like, am I going to have to like, am I going to have to wheel it out or anything like that, just for me. But no, it's really small and just beautiful and intricate, and I believe that he did all of the illustrations himself. So I think it just took a long time. I feel like he wouldn't have bragged as hard as he did in the description if other people were talking about it, because he goes on, he's like, on this day I did discover and the heart of sickness looked me. These are longitude and latitude lines, he's like, look, I was right here. Which I think is a really cool flex on everyone else at the time. Yeah. Do you have any other questions? Anyone else want to just ruin my selfies? Yeah. What were they used for? That's a great question. What were they used for was the question? So this globe was actually part of a set, and it was barely in vogue at the time for globe figures to make a globe of the Earth, where it would be actual cartography and then have the globe of the Earth be made with a pair of the sky. And I think one of the sky was more just for fashion than anything. People were definitely actually using the globes of Europe and Africa to plot journeys and whatnot. But as Europe's premier globe maker, you're making globes for royalty, dukes and duchesses and whatnot. I think that this one in particular was more, it was more about the cloud than anything. Yeah. Yeah, John? Were you able to meet Engel? Engel? Yeah. No! This is one of the greatest regrets of my life. I met Navne, my best friend Engel. I sent her an email, a follow-up email. I was like, by the way, I am? Oh, crazy thing! Turns out I'm going to be in Sweden this summer. I tried to play it really cool. I didn't want to embarrass myself in front of Engel. But it turns out that the Swedes all get six weeks or something like that of paid vacation. So she was all having a vacation. I had those slackers. But I did get a couple more very nice, very sweet emails from Engel. They went directly into the folder in my email title, Happy Emails. Just if I need a smile, just take a week. Maybe one more question if anyone has one? Yes. Way back there. Justin, this is a thoroughness. This presentation is all about being thorough. I'm very thorough. To authenticate the promise of the blow. No, no, no, no. I'll go. So yeah, the question was, what steps did I take to authenticate this blow? That was from Engel, a trusted source. You will not denigrate Engel in this interview. But I did go and I did check. At first I was actually worried because Cygnus, this part of the blow, for some reason that I will never understand, was turned to the wall. So I was worried. I'm like, I don't see my boy. I don't see where. I had to, I did maybe, don't tell Engel I did this. I did maybe scoot behind the table to be able to get a look and read the inscription myself. Frank Stoller, okay. Too many people to arrest this night anyway. Is that good enough for you? Okay, sure. Thank you everyone for listening. A round of applause for Kien. Hey, welcome back from the Rook Dwarf adventure, Chasing a Globe. And congratulations again to our two re-owners. Please give a very warm welcome to Astrobiology graduate student at the University of Washington, Okay, can everyone hear me okay? All right, I'll try to speak loud. Okay, so I'm going to give you, my name is Diana, I'm going to give you a prelude of things to come that is really exciting for the Exoplanets community. And those future space mission concepts that I'll be talking about has been designed, has been designed with the utmost integrity, Kien, with the question of understanding our place in the universe in mind. So these are, let me see if we can figure this out. This is a landscape of our kind of current, upcoming and future space mission concepts. This is for NASA, only the Europeans have their own missions, but I won't be talking about them. And in particular, Mouvoir and Havax will be directly imaging planets themselves while OST, the origin space telescope, will be observing the thermal emission from planets and what's called transit transmission spectroscopy, which I'll talk a little bit about later. So here are our players, I'm going to be mostly focusing on Mouvoir, which is illustrated down here. Okay, so like I was saying, these space missions have been designed to answer two fundamental questions. One, are we alone? And two, are we weird? So these two questions really encompass things like are we alone? You know, how do we detect the conditions for habitability when we detect signatures of life? Are we weird? What is the diversity of exoplanets and planetary systems out there? And so to answer these two questions, we really need a space mission that can give us statistical studies of many groups of exoplanets and also deep comprehensive studies of individual planets themselves. So before I talk about the future, I have to start with the present. So I'll give you some highlights of the field so far. So this is a figure that shows kind of the discovery slash detection space of exoplanets. So on the bottom here is orbital separation, that's the distance that the planet is from the star. And on this axis here, it's the planet mass in terms of Earth masses and over here is the planet's radius in terms of Earth radii. So notice that these are log scales and these different symbols here show you how they were discovered or the method of detection. So as you can see, there are huge swaths of space here carved out by these different detection techniques. Direct imaging, which is actually looking at taking picture of the planet themselves, is in this space up here, so very massive planets, very bright planets, out at very large distances to the stars. The transit method, which many of you probably have heard of with Kepler and Tess, is carving out this space here that's very close in to the host stars of these planets. Because it's easier to detect transits when the planets are closer, and the probability of transiting is higher when the planets are closer. And also there are some radiovelocity detections, which also favors closer in planets. So it's ridiculously missing in this discovery space, detection space, is look over here. We've got Earth, Venus, Saturn, Jupiter. This space that defines our solar system, we have no current meaning, means of really detecting. So this is an issue. Okay, so as Kepler and the transit method, it was really good for telling us something about the statistics, the demographics of exoplanets. So one question that we're all interested in is how common are Earth-like planets? So this is the new story that we get every month or so where we see a new Earth-like planet has been discovered. So when we say Earth-like, we mean that this planet has radii that's relatively the same size of Earth. It could be a factor of two different, it could be a 20% difference depending on how people define it, orbiting a star like the Sun in the same region of space as Earth. So it does not mean that the planet can actually host, is actually hosting life. So Kepler, one of the kind of crowning achievements of Kepler was that it was able to start to answer this question. So in the next plots, you'll see some symbols. This symbol here means the planet occurs rate density and it's just a fancy way of saying how many planets are there per range of periods or orbital distances per range of planet size. And once you have that, by looking at the data, at the transit data, then you can calculate the frequency of Earth-like planets around Sun-like stars by specifying some radius or size bin and period of bin. Okay. This is a conglomeration of results spanning nearly a decade of work. You'll see on the bottom here, this is a log space, so that means that this planet occurrence rate density is spanning from 0.0201. You're saying I can do math. This is a huge range and at first I was like, hmm, doesn't seem good, but I think the way to interpret this is not that people haven't been working hard on it. The way to interpret this is that there is a lot of uncertainty in this specific parameter space because the data that we have just isn't constraining enough. We have to extrapolate from short period data to acknowledge predictions about what planets are like to further out. A group of experts in exoplanets they got together with some community input and they were like, well, we can't, this doesn't look good. They got together and they investigated what was behind these discrepancies. Again, it's really a reflection of the uncertainty because the data isn't good enough yet. They came up with ways to standardize the calculation so that moving forward we could have a better means of predicting things. And so what they ended up saying was let's see, there's 8 of Earth here which is the frequency of Earth-like planets meaning planets with size about 0.8 to 1.4 size of the Earth in a radius, in a orbital separation that would make it be in the habitable zone so conditions so that the temperature is warm enough that it can sustain surface liquid water and they came up with this number here. And you'll see that there's a large range and that range, again, reflects the uncertainty. So this number is important because it has significant implications on what we can observe in future direct imaging missions. So going back to where we are in terms of direct imaging. So this is not looking at light from the stars and seeing blips of light like in transit but looking at the planets themselves. So this is the current state of the art with HST. This is direct imaging of the planet around Homo Homes. So the star in the center here is suppressed with a chronograph and there's a ring of debris, dust material and you'll see there's a planet here and it's going to move in almost. Really high tech stuff. No, it really is. What you'll notice is the scale here. This is 20 AU, that's kind of between the orbit of Uranus and Neptune. So this is probing very large distances from that central star. So very different from our own solar system. So in terms of characterizing the actual planets themselves we're limited to this technique called transit transmission spectroscopy and the way that we this is one way that we can probe the atmospheres of exoplanets. One thing to note is that transit transmission spectroscopy means that a planet has to transit or pass directly in front of a star in order for us to probe the atmosphere of that planet. So perhaps many of you are familiar with the transit method. What happens in transmission spectroscopy is here's a cartoon of it. Here's some planet with a really large atmosphere maybe this is gas giant. And you have some starlight and we're observing over there somewhere.  In transit transmission spectroscopy we're looking at different wavelengths of light and looking at how the brightness of the star is changing as a function of wavelength. And going back to this cartoon essentially what's happening is you have some photons from the star it's going through the atmosphere remember we're observing over here and some photons will make it through the atmosphere toward us some photons will be scattered away we don't see them or detect them and some photons will be absorbed by whatever molecule is in that atmosphere and when that photon is absorbed we won't... it makes the brightness darker because we're missing photons and so that translates to this these different sets of transit light curves here for different wavelengths of light the transit depths are actually different because the planet will appear more opaque at certain wavelengths that the molecules are absorbing and so the transits are deeper than at other wavelengths so if you kind of rotate this the other way around you'll see as a function of wavelength the planet size or the transit depth and you'll see that it varies and these two blips here so the further up it is the deeper the transit meaning the more photons are being absorbed so these two are absorption features of sodium so this is the long way of explaining how a transmission spectroscopy works this is really great but we have limited targets and this technique really is only great currently for really large gas giants orbiting around em dwarfs because of again that transit geometry constraint so we have to see planets that are close in we need bright stars in order to get enough photons to detect these things that means the stars have to be really close to us or intrinsically bright and statistically speaking em dwarfs which are the lowest mass stars are most common in the universe so they'll be closer to us and we need large transit depths to get signals so that means larger planet radii are smaller size stars so again em dwarfs so the takeaway is that again our current technologies we're probing the atmospheres on hot jupiters maybe Neptune or sub-Neptune size planets around mostly em dwarfs planets that are not like us why are future space missions interested in direct imaging pros are that we can survey entire planetary systems because you're literally taking a snapshot of the planets maybe asteroid belt debris stuff around it and we're surveying these planetary systems that are most similar to our own because direct imaging is sensitive to planets that are further out than other techniques and arguably we know the sun the best out of all the stars out there so we understand stars like the sun the best which is good in terms of how we can interpret our planet direct imaging we're directly imaging the reflected light from planets and with that we can better probe the atmospheres of those planets and we can even probe subsurface features we can't do this with transmissions but across the beam and you can observe the planet at different phases and this is important because if we detect a certain molecule of interest say oxygen we found some planet we can't say with certainty that there's life out there so in order to confirm these biosignatures we need to study the planets with as much observational information as possible so looking at the planet at different phases is one way to discriminate false positives or imposters we know fortuitous alignment required as with transits so we'll just get more targets out there if you imagine planetary systems are just randomly distributed on the sky at different inclinations statistics tells us that we'll get more transits however the cons are that we can't get direct measurements of the size or mass of the planets and also it is extremely difficult because because we're imaging when we look at the planet the star is also in the way we need a contrast of 10 to the minus 10 that's a lot so to give you a scale of oh ok a scale of things 10 to the minus 10 contrast is like imagine a firefly that's 6 feet away from some super bright searchlight that's great I can see the firefly right here what are you talking about well remember that our stars are far away so you're trying to see this firelight against the glare of this searchlight from a distance like from Seattle to Boston so that's a really really high contrast and high resolution problem so the answer is go to space and the answer is use coronagraphs so how does a coronagraph work and how does it help us detect the fake planets next to the really bright stars so I'm going to be playing this NASA video and attempt to narrate over it so we're searching for life habitable worlds and we want to detect these really really faint planets against the glare of stars space the final frontier I'm really excited about the car so we have some distant planets and earth and a Jupiter analog that's orbiting a star perhaps a nearby star in the solar neighborhood and now we're pointing a telescope at it the light from the star travels through space enters the telescope and is detected as a central source an airy disk with concentric rings due to diffraction to reveal the planets this coronagraph mask to block out the central source and then we use a Liostop to suppress the light from that diffraction pattern the planet because it's physically offset from the star the planet's light will come in at an angle and so it misses the mask and the photons make it to the detector however because in reality there are imperfections with the telescope here and the optic system those imperfections will cause wavefront errors which will imprint as this speckle here in the image to remove this speckle the telescope uses deformable mirrors to correct those wavefront errors in real time and so eventually you can see the planets out here and if there are enough photons coming from the planets we can pass their light through a prism to look at their spectral components so here are some light is missing and those light are being absorbed away by different molecules in the atmospheres of those planets so that's how that's called direct spectroscopy and that's how we can use them to characterize atmospheres of exoplanets like Earth that's far away so going back to future space missions Lvoir and Habax like I said in the beginning are focusing on this direct imaging problem so they will fly with chronographs and the main difference in Lvoir and Habax have very similar science goals to detect biosignatures on exoplanets but their ambitions are very different and so I will mostly talk about Lvoir tonight because I think it really tries to go boldly in its ambitions of actually surveying many exoplanets in order to say something statistically meaningful about these exo-Earths so we can actually place constraints on the frequency of habitable conditions and detect potentially life on other planets okay so what is Lvoir? it's not French it stands for the large UV optical IR surveyor so these are the wavelengths of light we'll be looking at remember these are space perhaps I didn't highlight it in the beginning but this is a space mission concept meaning that it's not it hasn't been decided that it will fly yet it will be decided by a panel of experts whether which of these missions will go and the Lvoir team designed two different concepts with one single architecture Lvoir is designed to be serviceable just like Hubble and the two different concepts are Lvoir A and B with the main difference being that Lvoir A is huge and Lvoir B is big so to give you a scale of size here's the Hubble Space Telescope favorite for now and this is the size of the aperture of the mirror so this is JWST which we'll launch soon of Lvoir B's aperture size and Lvoir A's aperture size it's 15 meters, it's huge so this is a video a simulation of how Lvoir would deploy this is after it makes it to the L2 position which is far further away than where Hubble is now so you see that the solar panels are coming out this is how the telescope will get energy here comes the sunshade this shields the instruments from radiation from the sun and from earth and other stuff now the secondary mirror into position and the primary mirror which is segmented will unfold itself in space and that's that so Lvoir has really powerful capabilities because of its really large mirror in conjunction with the chronograph that will be on it why astronomers love large apertures is because a larger aperture provides higher light collecting power so we're just we're bigger so we can collect more photons and higher resolving power because we're bigger we can tell two things apart further away better to illustrate the resolution power of Lvoir here is our favorite dwarf planet Plugo and this is with HST this is a simulation with DWST here's Lvoir B and here's what it would look like with Lvoir A really, really high resolution and another thing that's important for our interest in detecting large aperture gives us a smaller what's called an inner working angle so this inner working angle is the smallest angle on the night sky inside where you get really bad contrast you get stray light but outside that inner working angle you achieve that 10 to the minus 10 contrast so why does this matter this small inner working angle well let's use a toy model we have the sun and the earth okay we've got uh wow you can't see the sun at all on this projector okay believe me there's a sun here oh now remember why you can't see it the inner working angle the chronograph is working there's a chronograph here right and there's a inner working angle of some degree and it's blocking out the star light great we're observing this system okay and now let's say wow we should have put a line here to denote where the star is so this is the star here and this is the star here but as we look out at systems that are further and further away the planet will appear closer and closer to its star on the sky you're with me okay until I did not think this through until the planet down here invisible because it's within the inner working angle everything is working as it's supposed to alright so another way of thinking about this is that right instead of this being going from systems that are more and more distant from us we can think of it as this is a star that's like the sun this is a star that's a little bit less massive than the sun and this is a system where the star is an m-door and the reason why is because we want to image exo-earths and so an exo-earth will be closer to the m-door in order for it to be habitable than it would be for a star like the sun and so if you're imaging if you're looking for exo-earths around m-dwarfs that inner working angle will really prevent you from detecting them because they're within this inner working angle so we'll do some high level math here so the smaller your inner working angle the larger volume in 3D space will sample because you're looking at more distant you're able to see more and more distant systems and you get more stellar targets and so that gives you a higher exo-earth yield so this is with our toy model but with more sophisticated models we can see what the predicted exo-earth yield is for m-dwarfs for both the A concept, the 15-year and the 8-meter concept so instead of the toy model back here, here's an actual simulated observation of the inner solar system at 12 parsecs away with real noise properties so this is what it might look like and here is a figure showing the exo-earth yield along so it's 54-ish, 50-ish for luvar A and 30-ish for luvar B this is great news because it means that we can observe potentially many many exo-earths and potentially detect biosignatures on them you also get a lot, because you're imaging because you're taking a picture of these planetary systems you're getting, while you're searching for these exo-earths all different types of planets that might be in that system so you can get rocky planets that are not within that habitable really locked zone you'll get super-earths sub-neptunes, neptunes super-earths, all sorts of things so this is great for a versioning field of comparative exoplanetology so I'm going to see what the time is so I'm going to skip these because unfortunately time is limited biosignatures detecting life or science of life on other planets so again we can't send probes or rovers or landers or orbiters to planets outside of our solar system so we can only rely on the photons that we have and remote sensing techniques these remote sensing techniques by looking at the reflected light of the planets we can use these techniques to look to identify biosignatures so these are science of life in the atmospheres or perhaps the surface of that exoplanet so in particular you can look for specific combinations of gases for example oxygen and methane together is to be a robust protection for the potential of life and underscore this combination of gases here because you don't want to just look for one molecular absorption signal because there are many false positives meaning there are many non-biological processes that can produce different molecules in the atmosphere right it's only when you look at combinations of gases or molecules and kind of disentangle is it is that atmosphere in chemical disequilibrium meaning is there perhaps biotic sources that are replenishing fluxes that's keeping that atmosphere out of equilibrium so that's a robust detection of biosignatures and also you can look at surface reflectance features such as I'll talk about the red edge and the ocean glint and also you can look at time and also you can look at the non-biological processes so this is a fancy way of saying we can perhaps see seasonal variations so we know on earth for example that vegetation has seasonal variation can we detect that use that as a sign of life on exoplanets so in terms of okay one major criticism of I think the search for exo earth and life as we know it is people are like well we only have one data point that's earth well that's true and the counter argument is that you have to start somewhere so you have to start somewhere that you know but in addition to that I think what's really important to note is that one earth is really many earths and what I mean by this is that the modern earth as we know it is very different from earth in the protozoic and extremely different from earth in the Archaean so we can look to the history of earth to help diversify our pool of data against which we can search and identify biosignatures so this is a complicated plot but we'll focus on this left panel here which is showing if you tilt your head a billion years ago so this is like our sun was warming planet is warming and then we have some record in the rocks so this is four billion years ago in the Archaean so these here the different colors are different molecules in the atmosphere of earth as a function of time so this is modern, this is further back in time and one thing that you'll notice is that things like oxygen that we take for granted has not always been here at all so one thing to note is that on the left side here it's fewer stuff on the right side here it's more of this stuff so oxygen here, we've got a lot of it it's great but if we go back to earth's history the atmosphere was actually anoxic for billions of years the same thing if you look at methane methane was much higher in abundance back then it is now and the same with ozone ozone really occurs because of the rise of oxygen here and so again we can use these three different earths as templates when we look for life elsewhere so these spectra here are what's called albedo spectra so albedo is just a fancy way of saying reflection so these are reflectance spectra it's the amount of light that's being reflected by our planet as a function of wavelength so on the modern earth we've got a lot of oxygen the oxygen build up leads to ozone formation and so there's a huge chunk of our reflectance spectra here that could be eaten out being absorbed by ozone water vapor, very good we're telling us that there's liquid water and then back in the protozoic we had our oxygen levels was much lower and you can kind of see that this swapping signal for ozone which comes from the build up of O2 is much less and further in the Archean we had no really detectable oxygen in the atmosphere instead we had perhaps a reducing atmosphere with lots of methane and perhaps a haze so what does this look like what might this look like to louvoir so here is a reflectance spectra spectrum of an earth basically earth around a star that's outside of 10 parsecs away and you can see bars here denote simulated detection with louvoir A so we can pick up this rally scattering slope here that give rise to our blue sky we can pick up the water vapor bands and we can pick up oxygen absorption so with louvoir A if we were to observe those exo earth candidates remember that the 54 and the 50 and the 30 exo earth candidates if we looked at them for 12 months we can look at this full spectrum of 24 for louvoir A and 11 for louvoir B of those candidates that's pretty good that means that we're looking for in exo earth outside of our solar system we can try to detect for these water features and methane features around 24 and 11 of those in just one year okay so with the remaining minute I'm going to quickly talk about some other ideas about how we can look at surface features so this is a really cool idea I think as an astronomer I don't often think about earth and earthy things but this is cool because these are observations of earth's shine so earth's shine is here's the moon right this side of the moon is being illuminated by the sun so here's the crescent moon and this side is dark but the dark side is reflecting earth photons back at us the earth photons are reflected light from our sun okay mind blowing anyway you take a spectrum here and that's the reflecting spectrum of earth or earth's shine and here you see that at this time we were looking at the South America the continent here South America you know the Amazon has a lot of green stuff so you can see that the spectrum is slightly different from when we're just looking at mostly water and that's because of this red edge so the red edge is or the vegetation red edge occurs because leaves have a certain reflectance spectrum so chlorophyll which makes photosynthesis possible absorbed in the visible and so we're left with this red edge here we're looking at the reflectance spectrum of the leaf and this is two different scale what we observe here in the earth side earth's shine spectrum so this is one possible way of detecting vegetation on exo earth um I'm going to skip this because we have no time and this end here the question was I think when do people decide which mission to go ahead with and um the late 20 yeah right so when we're so when we're taking a that's a good question so the question was does it depend on the emission reflectance factor depend on the emission from the star so yes when we're directly imaging these exoplanets right we're taking a spectrum of an image of the planet and then we're dividing that by the flux of the star so we're dividing out whatever contribution the star is making so the question was have we detected uh any exo earth yet that the gist of it no we know no exo earth we know of earth size planets and the habitable zones of m dwarfs but with our current technologies we don't know any two exo earths and that's one that is the reason why we wanted to fly these direct imaging missions and actually survey different stellar systems close by to us and detect these exo earths so that we can look at their spectrum um I'm not the techno signatures expert that's again Jim Davenport um but I think that the potential for life as in like microbial life perhaps I'm thinking that's what we might detect rather than like humans because bacteria have existed on earth for many years before we even arrived they were here in the archaea and the provisoic and they were doing anoxic um metabolic stuff good question why are we looking for planets that are earth size so that's because a couple of reasons one is that physically right we know that there's a difference between gas giants and rocky planets we can't look for really life on gas giants and gas giants have larger radii because they have larger masses right but specifically why are we looking for in that like a 20% narrow zone in terms of earth size and that's because we don't if it's too small then likely it doesn't have um it's also not very massive and that means that it can lose its atmosphere like Mars has lost its atmosphere because it's way too small and also we know from the Kepler mission about 1.4 earth radii is this kind of statistical cutoff between planets that tend to be below that cutoff planets tend to be more rocky so they're denser and then above that cutoff um the planets that we observe tend to be more puffy so they tend to be more like gas giants or ice giants thanks everyone