Hello everybody So we're going to be presenting today open stack scale and performance testing with browbeat We're going to be taking the wizardry out of open stack performance So first off my name is Alex cross You can find me on IRC is Akersos and I work for red hat Okay, I'm Sison Malini. I work on the red hat performance engineering team And I'm will foster I work on the performance and scale team as well more on the dev ops infrastructure side So here's our agenda. We're going to be given an overview of browbeat We're going to have will is going to talk about the infrastructure. I'm going to be talking about the metrics collection and analysis Scy's going to be discussing the results collection analysis Sigh and I will go into some of the performance and scale issues that we've found Using browbeat. We're going to talk the future of browbeat we have a slide on How you can help contribute how you can get involved with us If there's any time we're going to take q&a If not, we'll be available outside the the hall there All right, so browbeat overview Probably wondering what is open stack browbeat? Well, it's a number of other open source projects all combined into a performance and scale analysis orchestration tool so you probably see a lot of familiar familiar terms there or projects like rally Elastic search perfect hit benchmarker grafana collectee graphite One other thing I want to mention about Everything that we do is we anything that we find like a problem in any of this software will open an issue or will We'll follow up We'll try to commit a patch in or try to help them enhance that software as well as we're using it So the true spirit of open source there so All right a little technical difficulties here This thing not anybody know any good jokes. Oh, we uh, yeah, so Plug it in there. So What is open stack browbeat? It's not a new workload It's not just a new way to gather metrics It is an orchestration tool We have a nice diagram up here. Hopefully it'll show. It's really good I would love that you're able to see it. You just got to take our word for it right now, but uh, but it's a way to We can install every the what we typically work with Triple-O clouds, so we have an under cloud and an over cloud and we install browbeat on the under cloud and from there We kind of launch we orchestrate all of our testing We can do the installation of all the tooling such as collectee It'll feed metrics over to you the graphite carbon server and then the metrics will be available and For viewing through Grafana And then all of our data plane benchmarks. They obviously run instance to instance above your computes Control plane benchmarks those will run from your browbeat Installation against your controllers We collect metadata on the controllers and the computes that way we can we can combine the metadata with the results data and we can We can then push that to elastic search so Okay, I'm just gonna Talk through why browbeat matters because there's already so many tools out there and what is new about it What is it helping you do so open stack has matured quite a bit over the years in terms of functionality, right? so More of the concerns that enterprises have around performance and scale and I can't go to the next point because I don't see anything here Okay So the other thought is performance and scale should operate and integrate like CI with open stack releases coming about every six months Or so you don't want to wait for a release and you know a bunch of performance engineers sit down and try to benchmark it It should be more like see I like how you push code and it tells you if it fails or it passed So your performance also should operate like see I your performance benchmarking And also customers and partners have a lot of questions around you know how many routers can I get on this environment? How many tenants can I get on this environment? So it's not possible for any one of us to answer every single question that a customer or partner has because Each environment is different and that model is never going to scale if you want to be able to scale You're going to be able to empower your customers or partners with the tools they need to You know be able to benchmark the cloud tune their cloud and whatnot So there's a lot of good tools upstream. There's rally this which is good at control plane the shaker which is Good at our data plane. There's all these results collection and analysis tools So they they're good tools, but they're good at what they do So we're trying to fill in the gaps here. So you take a bunch of new Upstream tools and you fill in the missing gaps and you give the end user an experience where he just fires two or three commands And everything flows from there and you can also Compare and tune your cloud for the best performance So that's how bra beat matters and the workload. So we have a simple yaml based config file So first thing is rally, which is the most popular in terms of benchmarking So we have keystone over a neutron and other scenarios We also have some custom plug-ins we built into it and the P bench plug-in scenarios are special in the sense that P bench is Is what we're working on a tread hat internally and we've open sourced it What it lets you do is pretty much benchmark anything VM or bare metal It doesn't care as long as you can SSH into it you can run performance benchmarks on it So we have P bench also integrated with rally so rally stands up the infrastructure and kicks off P bench So that's pretty neat there and we have shaker. So it does throughput latency TCP UDP Let's you spin up a topology. Whatever you want L2 L3 east-west north-south So and it also does a beautiful job of orchestrating several pairs of VMs firing bandwidth concurrently and we have perfect benchmarker, which is a which is itself a Combination of different workloads. It's got 30 or so workloads in it And the cool thing about perfect benchmarker is it actually lets you measure cloud elasticity It keeps a track of how much time it took to spin up your resources clean up the cloud and things like that So it's pretty cool So zero to performance testing. There's hardly like 10 steps on this slide But most of them you can actually neglect because they're Changing directories and editing configuration files. So you can pretty much get to zero to performance testing in these 10 steps So you set up Braubit you edit an ansible base Wars file that Tells where your elastic search instance is sitting at where's your graphite? Where's your Grafana? Then you set up your monitoring. That's also very simple You just run a couple of playbooks it installs collect the across the nodes and also uploads the dashboards to Grafana And then you jump right into performance testing.  All right. Thanks. I so with Braubit There's a lot of complex components to open stack So our goal around Braubit was to keep things as simple as possible and as repeatable as possible So when you look at the workflow Braubit is very simple. There's just about there's about four major categories and it just lets you run Braubit over and over until you get the Results that you're after but again, we're kind of aiming for simplicity here When we dive into some of the infrastructure tools as well You'll see that everything is Automated in a way that requires very minimal input very minimal post configuration if at all when things get set up All right, this is probably the most accept. Okay, please behave This is probably the most exciting part of Braubit for me It is groundbreaking and that It can okay. You have to take my word for this the stuff on the slides really really cool So Braubit will not only just do performance testing It also has an optional ability to go through and scan your cloud for known CVE's known vulnerabilities Things around like performance testing tuning values that might not be optimal. So it does a lot more than just run rally run perf run Shaker and all the other various tools that kind of comprise it. It actually will Give you a spit out of any bugs that you might be hitting any performance recommendations And it kind of fits in line with performance and scale being more CI driven and less kind of the the legacy way that people would do performance and scale testing where you know Heaven forbid you might shove your data in a spreadsheet somewhere You know if you're lucky you could write a white paper that no one reads after a year This is more involved and you actually get some very useful details Right away as far as how often while your cloud is set up Any performance tunings that you could benefit from and things like that so in a way This is kind of like it's kind of like CI for performance and scale I know that the upstream infrastructure folks are also looking to Braubit to do post-validation So after a new deployment rolls out they'll run through the Braubit test and then it should at least hit a minimal threshold of acceptable performance before it's deemed to be Usable by the general public Okay, so I'm gonna dump into some of the playbooks that we ship with Braubit and these are these are optional You don't have to install them, but we needed a way to Very quickly spin up ancillary infrastructure Via the elk stack Grafana graphite kind of some of the bread and butter tools that we use to visualize metrics and performance data So we ship two different playbooks We ship an entire elk stack. You have the option of using elastic search Log stash and cabana or you can use fluent D as well, and we also ship graphite and grafana With an optional ability to ship it through a doctor container if you are a doctor shop, and you like those better So kind of dive it into some of the elk components This is again optional and it's extremely simple one answer will come in you have a fully working all-in-one elk stack You also set up the clients for that as well We opt to use foul beat for the clients, but you can switch that out with fluent D if you like and Some of the highlights of the elk stack and we've kind of made some decisions for you We want to keep things as simple as possible But we're orient towards things like if you're running Performance test at a customer site or you're you're running at a partner site And you might not have access to a proper fqdn or you know You want to have one silent place to keep your data then pull out later So a lot of these decisions are made around what works best for us from a testing perspective You could take this elk stack and use it in your infrastructure for system logs or anything else But some of the options that we chose Everything is encrypted by SSL by default Some of this traffic may go over the WAN. So it's it's good that you have encryption The certs are generated during the answer will playbook run So we also add in alt sand support So what that will give you is if you don't have access to have a proper reverse and forward DNS name You can use IP address and a lot of small silo testing setups You may not have the liberty of being able to spin up proper DNS And you could cause issues and unless you go in there and actually create the search yourself So that's taken care of Another cool thing is that we don't make any Decisions about or try to make any decisions about what your infrastructure looks like everyone's setup is different So we set up IP tables rules for you It we first detect if you're using firewall D or IP tables or nothing at all And then we drop the a proper rule and then we make it persistent But we don't clobber your existing rule sets So we don't want to try to make any assumptions about anyone else's infrastructure We also do automatic heap size tuning with elastic search So we will take half of your system memory up to 32 gigs or And so the rest can go to Lucene indexes So there's just kind of little best practice things that that we've baked in there for you that you don't need to worry about We'll optionally install the curator tool as well And we have some cabana dashboards that we ship that's optional and again everything's configurable in yaml files Same sort of thing with graphite and grafana Just just one ansible playbook. It'll set you up. Everything's automated So if you're curious you can look at the github there and take a look and Again some cool stuff with graphite and grafana everything's automated the database creation the user creation We really just want to simplify very quickly setting up ancillary infrastructure for you to either host your test results Or to have something longer running to benefit you save you time All right, I'll be talking about metrics collection and storage analysis so we use a collectee carbon graphite grafana stack to Collect our metrics store the metrics and visualize the metrics collect these lightweight Damon That's what we use to push metrics out of our systems Carbon will then receive it and write it into whisper database files Grafana is the really pretty part that everybody likes to see so we're gonna kind of jump right over into that With browbeat we ship with a number of dashboards because If you ever use grafana, you know that you've got to configure it yourself And there's a lot to learn there and figure out especially when you're dealing with metrics for the first time so we include static dashboards cloud specific dashboards and Generic generated dashboards. This is an example of the static dashboard. What we can do here is we can actually compare Two different clouds two different nodes from the clouds or you can do the same cloud the same node and then compare disks interfaces different process metrics there so you can see we compare CPU and memory right there So cloud specific dashboards are really to help you visualize what's going on with your controllers your computes and your undercloud and We'll do this by visualizing everything on the same single pane of glass your CPU memory disks or a network so here's An example of the CPU one you can see the top graph is actually the under cloud And then the the next three graphs below there are three controllers and that's a set of 96 keystone benchmarks Orchestrated through browbeat run from from rally So here's what the memory looks like. I just wanted to provide a View of what the memory would look like using these dashboards as well Here's what your disk utilization would look like we actually ship Several main chunks of this dashboard here So you have the percent utilization of your disk so you can very quickly see if you've saturated your disks or not Which if you're working with older hardware or older disks, you'll saturate them real fast and You want to know because your benchmarks are going to perform horribly We also have IOPS and throughput as well and for network we do packets per second and throughput and You could also select with Grafana You can always select what interface and this selects it for whichever node type you want So this visualization right here You can see how traffic is leaving the under cloud and going towards over cloud controller one Our generated dashboards are specific to the under cloud controller compute sep. They're basically We take a lot of ansible YAML and we generate a large chunk of the dashboard so Let's see here You can see we have a number of rows that we have of different metrics that we have pre Pre-baked pre visualized right in there. You just have to expand the row out. Obviously if I expand it all these out I would need a humongous screen and There's just a number of things that we collect and graph here also with the the cloud specific dashboards you can see that will tag A dashboard and will tag your CPU disk memory network all on one all in one tag there So then you can use the tagging port to to select which dashboard you want to view So here's what some of the per process metrics look like Going off those same 96 benchmarks here. We can see what the utilization is off of Apache as well as there's you know keystone Neutron and Nova so those 96 keystone keystone benchmarks that we ran was Authenticating key with the keystone python client then authenticating with the neutron client and then the Nova client so you can see Exactly when those benchmarks ran and how much CPU is being used for those specific processes now It is an aggregation over all the workers. So do remember that part You're not going to get down to the very specific process there unless it has a process title that we can separate on Here is a view of what process and thread counts look like and this is a What's interesting here to point out is the same set of benchmarks But you can look at the threads of my sequel and you can see how each we go through the first set of keystone benchmarks and the threads is a certain level and then once we hit neutron the threads grows a whole bunch and then You can see this giant drop here That's some threads timing out at that point and it's staying at a certain level with the Nova validation benchmark This is the the plug-in we use with my sequel so we'll gather a lot of my sequel metrics as well Including the threads the number of threads that are connected the traffic that's going on Another very interesting way or thing tooling that we can use is it how quickly we can find out if we've We've hit the brick wall because it's no It's really no fun at all to try to evaluate performance after you hit the brick wall You're not going to get numbers that make sense and you're going to waste a lot of time debugging so We use the tail plug-in to look for error messages So whenever I start to see error messages, I know at that point I got a discount the rest of the benchmark All right, so Okay, I don't want to stand here Mess with the wire. Okay, so Results collection and analysis So for the longest time ever performance engineers have been using spreadsheets spreadsheets are great They're awesome, but you know, what if you get to a point where the overhead of managing your spreadsheets is Much more than the effort it takes you to generate your results or your performance benchmarks So this is going to be the underlying theme of the next part of this presentation. So So making results meaningful. What do I mean when I say making results meaningful? So what if I had a data store where I could store My benchmark data my performance results possibly perpetually what I think what if I could easily query and search it? what if I could Aggregated do all kinds of statistical analysis on it and I could also easily slice and dice data so I can visualize whatever I've collected until now and because this so-called data store is perpetual I'll be able to plot Historic trends and whatnot so basically what I'm trying to Do is get more value out of my performance benchmarks or my performance testing data So letting json craft results so each of these workloads We've talked about rally shaker and perfect benchmarker. They output json's But we got to keep in mind that these json's were not built With the idea in mind that they were going to be ingested into elastic search for sure They're ingestible into elastic search because they're json's But to be able to get the same kind of value out of data like you see here It's create and list routers which each atomic action displayed in a different color like creating a network creating a subnet And each of those sets of bars is Corresponding to a different count of neutron API workers So to be able to slice and dice data like this the native json that is output It is not needs to be massaged and needs to be worked on and we'll go into more details later Okay, so just talking about the high-level tools we use here ansible most of you know ansible So it's simple ID configuration and automation Elastic search so this is like, you know simply put it's a search engine So you could put data into it and you can search and you can query anything that's a json Documented can be an object in elastic search and kibana. It's more like the interface into elastic search So you can query you can visualize data. You can give shape to your data using kibana You stills are really important. So we're gonna focus on it for just a little while Okay, so Still doesn't change Okay, so just trying to put it all together, which is the next slide. It's got an awesome graphic bird Unfortunately nothing works today.   It grabs the config data It grabs data about how your open stack is configured how many workers of NOVA there How many Nova scheduler workers are there and as such it also grabs data about your hardware about what kernel you're running and whatnot And it outputs them as different json's one for your environment one for your software one for your hardware So there's different json sitting in there and once your benchmark run completes Bra beat also massages your result json so that it's in a form that Gets you the most value out of elastic search and it combines this this metadata with the data and Ships it over to elastic search using the elastic search connector We provide and the end user can look at Kibana and query and get his visualizations So all of this happens on under the hood the only thing you'd have to change is enable elastic search in your config file and Also, of course, you need to have an elastic search instance and you can spin it up quite easily using our ansible playbooks Okay, so metadata. Why is metadata important? We're talking a lot about metadata and that we capture metadata about the cloud But what makes it so important? So if I give you a spreadsheet or a document with a bunch of great numbers great results What can you make out of it unless you know anything about the environment anything specific to the environment? That's not going to make any sense right the numbers are great But to have some value from the numbers you need to know what the setup was like So metadata actually adds more value to your data. So it captures configuration details and It also captures how the test was set up like in the case of shaker It's already in the json, but we ship it in a format that's easily query bill by elastic search So how many VMs were running in the case of rally what what the concurrency was and what this ultimately enables you to do is? When you have your cloud you run some performance benchmarks All of this is shipped to elastic search And then you tune your cloud with a new worker count or something like that and you run your performance benchmarks And simply you'll be able to query Elastic search based on sale. Let's say the query term we have here is open stack underscore neutron underscore api underscore workers That that is 32. So I only want to see results when the neutron API workers was set to 32 So I'll be able to do things like this with metadata being shipped along with result data Okay, so metadata to the rescue This slide is more of a screen scrape from rally and a screen scrape from kimana The brabeat scenario we were running was a rally one where we were trying to create and list routers and the thing that that was different here was There were two runs of rally But each of them had a different count of neutron API workers one had 24 on a 24 core machine And the other had 48 on a 48 core machine So each of these colors represents a different work account, but if I just looked at the rally Report, how would I be able to know? What the work account was when I actually ran the test unless I make a note of it somewhere or unless I Name my rally result file to reflect the work account. So how am I ever going to know what the number of workers was? So this is what metadata helps us do so it helps us query results based on the actual test environment Something okay, so bringing data to life using kibana. So what do you see here is? Keystone performance so going along the same line keystone performance benchmarks, but the only thing that's That you can see here is that we're doing performance benchmarking with one thread and six threads And how is it going to compare so with kibana? I was able to plot the concurrency of the rally scenario on the x-axis and the response time on the y-axis Lower being better because it's response time and also because I have the metadata about the number of threads I was easily able to slice and dice data and split bars based on the worker count or the threat count So let's jump into the next slide and we can see You know the kind of power kibana gives us Okay, so the next slide is about the same benchmarks But what if you switched your keystone token type from you ID to for me? So you'll be able to split charts based on that we've spent so much time on the tool that we've had to make severe compromises in our presentation integrity, so So worthy sacrifice though Oh I don't I mean all these lights have this picture. So Okay, so what I was going to show the next slides was How I visualized network performance data using shaker and how I was able to you know separate out DVR runs from Legacy runs so DVR is distributed virtual router routing So you have your router sitting on your compute node whereas in the legacy case is just on the controller nodes Awesome, so this was the next keystone chart I was going to talk about so the chart You see below is with the keystone token type set to for me and the chart you see above is with the keystone token I've set to you you ID so you can basically Split charts also based on your metadata So these are some of the shaker visualizations because the shaker data is an elastic search now I can also separate results based on whether they were DVR or legacy You can see this particular case is DVR east-west with both instances on the same compute node So pretty much your traffic never leaves your compute node So you see much much higher throughput in the case of DVR So you can also do line charts and you can see the query I put in there exactly so that's how I Pull up these results So what was the what was the number of VMs? What was the concurrency was it a bi-directional test was a TCP download or was it TCP upload? So and the best part about it you don't have to build most of these dash dashboards You just run this simple ansible playbook and it sets up the dashboards for you So once you have elastic search indexing enabled Automatically, probably is going to keep pushing data to elastic search and since you have the Kibana dashboards installed You can pretty much relax and look at your results So this is one more slide about aggregating results going back to the same 96 sets of Keystone benchmarks where each of them was run with a different concurrency and as such So if I had 96 different rally reports, not good, right? But what if I had a single dashboard that we already shipped to you and you can just pull it up and see How Keystone was performing all along this benchmarking process. So That's the cool thing about this. So So we have this cool tool. So you might be curious, you know, what are the different issues we run into it? Trying to find out with it. What are the different scale issues we found? So let's just go over it So DVR with floating IPs so the brabeat scenario we use here was simply Buddha VM On a subnet and try to ping it with a floating IP. So obviously if you see the red arrow there That was the time taken for the VM to be pingable after it was an active state So the dark color you see there, that's legacy routers There's no bar corresponding to that on its left side. So that means that It was so small in the case of legacy that you can't even see it on the scale of this graph But in the case of DVR, it was taking much longer to for the VM to be pingable So we just dig deeper into it and it turned out to be a kernel issue. So these are things you can Find out and there's obviously value in looking at individual rally Charts where you can see the particular iterations that took so you can see that it was not always happening But it was happening only on a few instances. You can obviously do that with Kibana too, but you'd have to do a different query based on that So metadata proxy memory growth. This was the other thing we we hid so creating and listing routers using rally 1500 times so you can see how the metadata proxy grows in memory. So this was the other issue I'm just gonna go on high level here in the best interests of time So sometimes or most times people use their open stack cloud with the default So what if we were shipping bad defaults? So this was one issue we hit so with Newton the way Triple or treated the default configuration in the configuration file it changed So it was not defaulting to the number of cores. It was actually defaulting to a single worker So these are issues we could find out running probably because we have the metadata about the cloud We knew how many workers were there and we could easily figure out, you know We were configuring bad defaults and these are not defaults that we should be shipping with and this issue was resolved after that So heat engine memory usage, so I just like to point out that we also monitor the under cloud So once you have our playbooks once you run our playbooks and you have Grafana graphite everything set up You can actually monitor your under cloud while you're deploying so you can see that You know how the heat engine memory usage is growing when you're scaling up your computes from 30 to 60 to 90 and as such I'll hand it over to Alex now Okay, so I'll talk about keystone token performance There's obviously if you work with keystone There's many ways to many major options that are we performance impacting your deployment model If you're an Apache your process versus your thread count that you can set up for the whiskey daemons Your token type so the scenario that I ran here with Braubit was to quickly represent a change in the process and thread count there so This is the Braubit scenario file that I have there the YAML and I ran through four different Concurrencies on rally and I ran it a thousand times and Here is the results Didn't update Okay, so this is the cabana results here You you could basically see that top left would be for measuring the number of I'll just do a count of how many results I have for each concurrency, so I want to see a flat I know that I'm comparing to you know one result with 24 processes And one result with one process and then the lower graphs are the response times itself, so lower is better there and you can obviously see that the the red one is one process and The bluer color is 24 process So the more process you have the better the response time is going to be and we want to look at the minimum Because you can see at certain times that 24 processes might not perform as well as a single process in certain situations But then when you look at the maximum as well as the 50th and 95th and 99th percentiles, you might you'll see different attributes there So the other big thing is we obviously want to check the system performance as well So the first thing I'll do is I'll make sure that when I tuned keystone that it did what I what I wanted it to do So I'll look at the number of processes that are running there And you can see it's one and then it's 24 And then below that you can see when I ran the keystone benchmarks. I was pegging out that single process And then after I tuned it you can see that it got access to more CPU Of course more CPU is going to cost something it's going to cost us more memory So we want to look down just a little bit further at the amount of memory So another situation that we've run into that we started testing with Braubit is just on the telemetry side So what I've done there is I'll set the polling interval down to 60 seconds And then I'll boot 20 instances and I'll sleep for 20 minutes And then I'll have that repeat until there's 200 instances then I'll just analyze the system performance I was really interested in looking at no key, but we don't quite have no key benchmarks yet that are out there that were that were utilizing You can see when zero instances was booted all the way up until we had 200 you can see the CPU there It's pretty well pretty well saturated So at that point we consulted with some telemetry guys and looked through the configuration We found a way to tune that tone back The amount of time it was for processing the delay in between processing the actual metrics itself So we tone that back to 60 and you can see the giant relief in system performance there So Braubit future The biggest thing that we really want to go for with with the future of Braubit is to kind of mix and match the workloads So I want to be able to maybe boot 20 instances under my cloud then run some perf kit benchmarks and boot 20 more So we kind of want to have a bigger mix and match of the workloads because right now it's very static where I'll run like rally Then I'll run perf kit then I'll run shaker We also want to be able to create workloads such as like running Ansible where we can we can Tap into our ansible playbooks to adjust the cloud make some changes rerun those same benchmarks Help us with the automation factor there and seeing what what tunings look like In our in our results graphs as well as in our system metrics graphs contributing to Braubit So you can find us at Braubit project org you find us on free node And we're part of the big big tent Part of OpenStack. So we are on our github. We have a gear and launch pad All right question and answers. I think we got three minutes And if you have a question try to use one of the mics as well, please so we can we can hear it Nothing works in this room. So bear with us. Oh, what kind of environment do you need to have to run Braubit? Like can I run it in a VM? you can but Taking any sort of like performance metrics and measurements out of a VM is going to be pretty difficult to get accurate numbers I mean recommend bare metal. I'd recommend bare metal We can if I can get that one slide to show that couldn't before it might help you out If anyone has a small animal we can sacrifice to give us better luck on the presentation I'm a cat but I left them at home This is generally what we recommend a piece of bare metal for your elastic search a Piece of bare metal for your graphite carbon and then I'd recommend bare metal for your controllers and bare metal for your computes obviously Your under cloud I would do that bare metal as well. I've done that in the past as a VM But to run Braubit if you're just doing control plane if you're doing just benchmarks against the over cloud Then it's fine to keep your under cloud virtualized But you want to look at the system metrics as well See if there's any contention that you're running there if you're running out of CPU just from running the benchmarks there Obviously, you're not going to be able to drive the system with a hard enough load And one more question real quick because are you integrated with DCI yet? DCI that's red hats. Oh See I There is some components that have been integrated the CI. I'm not the expert on that that side though. Thank you So there's a lot of language throughout this presentation and throughout your code about under cloud over cloud Is it possible and how difficult is it to run it without triple L? So to run it without triple L you just have to generate pretty much generate your own host file And there's probably a little bit of configuration you might have to do on some of the workload providers Such as maybe a perf kit if you don't have like an over cloud RC You'd have to name your RC file over cloud RC or edit we can edit the code We'd love for you know other developers to help us build that functionality for other installers So at the end of the day, you're still talking to APIs too. So it's not that much different Looks like we're out of time. So Thank you guys


I want more highs, but I also don't want to make it painful, so I'm going to add that this a sidechain compressor or the SR. Yeah, the SR. I'm going to use it in split mode, so we're hanging again. Too much stuff or I can't handle this track. Nice.  I think that the mix is where it messed up a little bit in here. Also, I want to compress it a bit. Copy the bass, the drums. Well, well, well, well, let's just select all of that. And do alt D. Oh, for the best. Is it there? Can it be there? Oh yeah, nice. And two more times. I could actually go shift D and just type three. I wanted to verify the first duplication first. Before I do this stuff, let's listen. I want to automate something to change up this part and this last part, too. And I think I'm going to try to automate something in Oxy. I'm going to see. Maybe at first I'm going to try to perform it live. Okay, I'm going to try to automate the chorus operation operator D course tune. Yep. You never did that before. 046. Okay, I'm going to insert here 0.046. Good. Now insert again here so I don't mess it up. Well, well, well, well, and now turn on the play and see. Does it work? I don't hear a difference. I think it should be operation D, actually. Yeah, it was operator E.  Or at least not as important as operator E. Yeah, okay, let's get this destroyed. All right, again, automation, Oxy, FM, operator E. Operator E, chorus tune. This one is just in the middle. Sweet. Okay, let's see what we can do. Pretty freaking awesome, if you ask me. How about this? And then reset. Or just this. Sweet and nasty. I think this is very, very nice. Let's listen in context. I just, I just hope, I just wish it would like not make some so much stair steps. Well, that's pretty painful. I think I need to do something about it. Yep, I think we need some solid DSing or maybe a dynamic EQ. I don't know. Let's try a dynamic EQ. Okay, so because we have painful frequencies. Okay, I'm also going to turn this down because it's just, I think it's better. Not sure. It's not perfect, but it's better. I'm also going to add just some static EQ. I think I have way too much, too many plugins in this session. I think the bass, this bass is a bit too loud, by the way. Yeah, I think I'm going to try to turn it down. All right, I had to restart the whole machine because it just got hung. So our whole business with the automation of OXC FM synth operator E is lost because Ardor doesn't auto-save if you don't record audio and edit audio. And on version 5 at least. Well, so that's weird. Fuck, I need to redo this. Okay, but hopefully I already know what I wanted to do. So it shouldn't be as bad. Yeah, but yeah, it's bad. Everything is lost. Well, fuck, I wanted to go as high to this, see what happens. Okay, kind of kind of kind of working. Maybe Ardor didn't like the dynamic EQ I used. I don't know. That's so painful. My goodness. I have to fix this. It's just terrible.  Okay, let's solo the instrument. Let's make it quieter. All right, this ain't going to work. Bad, bad news. Something's messed up. Oh, because the bass reverbs. Let's listen again. Pretty okay. I want to have more ghost snare boost notes. Hey, I want more of this. Let's see. Can I copy this here? I think there's kick missing, isn't there kick missing? Try. Okay, so we're not playing music with the snare anymore.  I don't remember what there was. What was there? So I can redo it. All right, so this was too high. Let's try that. How about this? Pretty sweet. System of the bass. Maybe save it. I love this breakbeat. Wow. You know what? I need a sub. I need a sub mix for the basses. Because they are all over the place in terms of loudness. And I just need to wait to unify that bass. Okay, all righty. So how do I do this? Because I think all basses go to the side chain bus. But okay, I'm going to try to move them to the side chain.  I'll explain some problems.  Ah, okay. Okay, that'll make sense. No side chain bus, dude. Now we need bass sub mix. Okay, any other basses? Yeah, there's the space too. Whoa. Wrong button. Not side chain, but bass sub mix. And the freezer too, please. Bass sub mix. And bass sub mix should go to side chain bus. Hey, and the sour bass. And the sour bass should also go to bass sub mix. Fuck, that's not good. All right, let's do this. Let them go. I'm going to just use automation to disable the side chain compression there. Side chain bus.  Play. All right, now the bass sub mix can have. A compressor, I will unify the loudness of everything, hopefully. Why is there no, why didn't this play? Okay, let's listen to the basses across the whole track and see if they are. All righty, pretty, pretty okay. Still, I feel like the drums are quieter here than they are there. Maybe it's because of the change in. And the change in, no, notice the crash there too. All righty. Pretty, pretty fine. I think I just want to copy the intro over or intro and this part too. Basically make it an accolade, I think that's the term. Make it feel like it's coming to closing a cycle. Okay, let's control C. And now go to the end of the things and do control V. This should be here. Now wait a bit, because there's a lot of clips to copy. And Ardor makes a duplicate of every single MIDI file there. And every region is a separate MIDI file. So it's probably like, you know, duplicating hundreds of MIDI files right now. It just takes a while. I'm glad this track is coming, like coming together, making starting to feel legitimately interesting. Oh, what the heck? What the... Oh yeah, all right. Why is there... Why does... Why doesn't this play? Oh, I have this muted. Why muted? Automation, all right. How about I copy the drum pattern patterns and reuse them here? Okay, I'm not going to start calling this these sections what they are sometimes. Let's call this F for no reason. I just, you know, need a little bit of a reference. Don't know where my drum things are. Okay, let's copy... Oh, it's not everything. Let's copy and now let's paste it here over to this stuff. Hopefully it's gonna replace it nicely and allow me to like, you know, give this this beat that is already used and use that maybe also do something with the bass. I don't know, it's taking a while. There's been lots of RAM. Oh, what? Okay, that's why I did... Yeah, 13 gigs. Did it work? Not yet. It's still waiting. It's not, it's empty. Why is it empty? Oh, it's probably because it was the first one in the session and got cleared. Yeah, of course it did. Let's change the name so it doesn't do this again. Yeah, I'm gonna teach you everything about avoiding bugs. How about actually swapping these two? That would make more sense, I think. Yes. Okay, how can I do this easily? Maybe just use this automation. Yeah, let's just do this. Copy this and paste it here. Then copy these two. All right, cut them, paste them here. Right, now just move this bass here. Should work, right? That's a pretty clever ending, if you ask me. I like it. I would just like this phaser to do some more motion after that, afterwards, just let it just die so badly. I have tried to use three verbants. Yeah, I have an idea. I haven't seen this. What is this? Okay, maybe let's not experiment with it. Actually loading up plugins that you never used before is very dangerous. You can just crash your session. Yeah, freeze mode, this is what I wanted. Yeah, that's gonna give me this very cool sound. Okay, three verb, freeze mode, this is what I want to automate. And I also want to automate wet level, because I just don't want this reverb to do anything for the most part. Okay, so I just wanted to activate the freeze mode here and make the wet level here, let's see if it works. Now, there's one cool plugin, like BitRot plugins. I want to, yay, tape stop. I want to use this. And I'm going to put the play stop after this. Activate it, just make it hang, and then just tape stop it. I didn't switch this. Yeah, also want to make it slower. Okay, I wanted it faster and I actually wanted to fade. This doesn't sound good. Pretty great, I like it. I wonder if I can use these effects somewhere else. Yeah, I think I could. Yeah, let's do that. It's going to be really, really awesome. Okay, let's automate, let's activate freeze for this and make the wet level here, 0.5, because that's a good level. Now then go back to 0. Then we can mute and unmute it, and I could just, I'd like to actually make some room for this. Like, let's not have any trumps or automate them so they disappear. Save them, go up, and copy the same thing there as well. Control C, Control V. Okay, let's do it again, because why not? Let's do it here, whoa, not here, not here. Yeah, not here. Okay, one, two, three, four, this. Oh, wow, something's, I think I just, I don't know, I'm missing it. Let's also copy this automation, because why should I have to redo that at all? Okay, let's do it here, and here too. Let's try. I think I could also make this louder. Here, rise the wet level. Oh, this is really awesome. It's real. Oh, this doesn't belong here, though. I'm going to un-mute it, and remove this drum automation, because the drums need to hit here, and to hit hard. Yeah, so after this one, I can basically disable the freeze mode. Tape stop, no, freeze mode. Disable the freeze mode, and bring the wet level to 0, just to play this. I think it's pretty cool. Save it. I think we could add some more cool, small cool sounds. Tiny glitchy thingies, I think it's going to be fun. We had a few of those, and they turned out very pretty well. Let's try it with more. Oh, my keyboard. Okay, sorry, gotta activate the MIDI bridge, I guess. Export hardware ports, yes, start. Okay, let's go with the Innet patch. Let's make it very low. Interesting. I think, again, the note pitch is not enough. Oh, where's the... Oh, there it is. Let's go V127. Oh, my goodness. All right, I don't want this to be a bass, so let me just call this FX3. And give it some reverb and hype as it, because we don't want the bass. Well, that took a while. That took a big while, a long while. Okay, I think I want to do something weird. Awesome. I just want to make it less cranes, see what happens. Oh, my goodness, it's so unresponsive. I think I need the NQ. Oh, I have one. My goodness, every single click takes forever to execute. I don't know if the video recording is going to be any good, because this is so unresponsive. Oh, where is this note, yeah. I want to add some delay for that. The triple. Let's make it give it more feedback. One, two, three, four. One, two, three, four. Let's try it. This. This work. What? What was this? Copy these to... Maybe to the last part. Try to bring some... Oh, this didn't copy or did it? Ah, it did, but... Oh, it didn't. Oh, it did. I don't know. Nice. I think I would like to try some reverser on the drum bus too, because that would sound really cool. Especially like, you know, you think like, this is something you can't do live with plugins without bouncing it to audio and then processing that, but you can. Just need... A little plugin called BitRot Reverser. Super awesome. I definitely want to use that. Yes. Yes, yes, yes. Just listen. Not everywhere. Should be just accents. I think this would fit for one here. Maybe a... Maybe a tiny small one or two small ones instead of one big. Instead of a big one. Yeah, that's awesome. Is there a crash? Because I can hear it. There is no crash. I want to crash here, please. I want some reverser too. Reverser here too. Yes. How about this? Oh, no, no, no, this, no, this lane. This lane. I want to reverse the snare. Yes. Fantastic. Let's try it here too. Right here, maybe on a longer part. See what happens. Like reversing kicks. I really hear it, but that's not... That's bad. Oh, great. I love this. The reverser really gives it... Makes it feel like another different level. It's... I really love that. Oh man, I'm gonna make a whole list of plugins I used, which is gonna be long. Really freaking long. I wonder if I can somehow generate it. Okay, I want to make some other cool sounds like this. Maybe let's try use dexit for that this time. Because I have a few spare tracks. So yeah, just let's try and use dexit. Let's use a mono to stereo splitter. Do I have something like that in the favorites? I don't. Okay, let's go with split. Oh, we've got to wait. Splitter, mono to stereo splitter. Let's add it to my favorites. Oh my goodness, it's so unresponsive. Okay, that's some weirdo patch. Hello, dexit. Can you... Yeah, in it. Oh, good. I missed that button in... I missed that button in auxcfm synth. In it. All right, so we can sum two things. Oh, that's gonna be interesting. Where's the pitch? We'll see. I want to be a bass. Oh, why not? Okay, nice. Pretty weird. Like it. Okay, four. So four is a separate thingy. Really weird sounds. I like it. It's pretty weird. Let's see what we can do with it. Can we maybe... Yeah, this can be interesting. Well, it's pretty interesting. Yes. What can we do to really mess up the sound? I had a whole bunch of very, very fast delays.


I am Dr Devanand, Head of the Cardiac Surgery Department at Manipal Hospital in Bangalore. We know that the world is going through one of the greatest difficulties which has ever faced in the last century. This COVID-19 which has affected everybody, every country, which has become a major health issue affecting different aspects of our life. There are certain rumors or certain concerns about cardiac patients especially being at slightly higher risk of getting into fatalities if at all they get the COVID infection. We are still not certain. There are some medications which are anti-apotensives like ACE inhibitors which are said to increase the fatalities in those who get the COVID. But till now there is no clear cut evidence as to say those these medications are going to affect in a bad way. In fact, there are some studies who are saying that now that they may even help to some extent. So at this moment the advice to our own patients would be those who are on ACE inhibitors or ARBs as a part of your heart care, please continue that without a doubt. Don't stop these medications on your own. Other medications which have been taken for diabetes and hypertension probably are okay. Please continue to take them. Don't make any changes on your own. Those who have really you know ongoing chest pains, breathing difficulties, they need not have to worry. They can always approach the hospitals. We are here to help you out whether it is operations or any other interventions or even investigations. Those patients who require follow-up, there are two ways of doing some patients who are close by and can easily reach us. Yes, our outpatient departments and other things are all functioning normally. You can meet us either physically if it is possible or even through the tele-consentations. One can go through the hospital website, how to go through these tele-consentations. We are all available to advise you, answer your doubts and take care of your concerns.


And here we take a presentable category. Everything just, the pattern just repeats itself. So maybe I should first give a definition of what Topos is. It would be very abstract. Suppose that E is a complete category. Oh, I'm sorry, co-complete category. I will say it. So maybe I should draw a picture here. Okay, so here are posets. And then in the theory of posets, you can talk about, for example, the enthema, the meat between A and B, or Suprema. And of course, you have also enthema, as well as Supre joint. So this is called meat. This is just the finite, the enthema. When it exists between two elements in a poset, it's called the meat. Just a terminology. This is called the joint. Now, if you replace poset by categories, then you have also the same thing. Here, this is called co-limit of a diagram. So you have a diagram, and you take its co-limit. Here you take the limit of the diagram. And here you could take the co-product, or more better, even the amalgamated co-product. And here you take the fabric product. Let's see. I said that a category is, I'm sorry, a lattice is called a Sup lattice. A Sup lattice means that Sup lattice is poset with Suprema, arbitrary Suprema. So that's the notions of a Sup lattice. But there is a notion of co-complete category. It's a category closed under co-limits. So a co-complete category is very much like a Sup lattice, if you like, in the world of categories. There is also a notion of a complete category. It's closed under limits. No, here everything is small limits.  Okay, yeah. For finite limits, I like to call that Cartesian. You don't like. I can say it's finitely complete. Oh, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah. It's like saying that a poset is closed under Suprema. We could say with, yeah, yeah, yeah. Yeah, it's an abuse of language, right? Yeah, yeah, yeah. But in writing, I can make it straight, yeah. But Grotenzik had the idea that when you take a limit of a diagram, you take it in the category of pre-sheeps. And if, so the limit always exists in the category of pre-sheeps. And if this limit is actually representable, then you say that the category is closed under limit. So if we adopt the point of view of Grotenzik, we can use the word closed. Okay, so it's not completely wrong. Okay, yeah. Okay. So what is a presentable category? Presentable category is a bit of a technical notion. Roughly speaking, it's a co-complete category with generators. Let's see. A small set of generators. It's not too wild. It is generated in some nice way by a certain set, a small category inside. So I could take some time to explain to you what is a presentable category, but I'm afraid that it may use a lot of my time. So I will suppose that this notion is known, but I'm writing some notes and I will make it, give the definitions in the notes. So presentable. So an example of presentable category is that if you take A, a small category, then you take pre-sheeps on A, which by this I mean contravariant from A to set, which are, of course, also the same as co-variant from A up to set. This is an example of a presentable category. In this case, the generators, it is generated by A. So you have the unit of function in the category of pre-sheeps. And every object, every pre-sheep is a co-limit of representable. So that tells you somehow that the category of pre-sheep is generated by A, but not only it is generated by A, but it is freely generated by A. It is freely generated. That's very important for the category of pre-sheeps. Exactly. So what this means is that if you have a function here from E into a co-complete category, then there is essentially a unique way to extend it into a co-considuous function. I forgot to say what a co-considuous function is. A function is co-considuous if it preserves co-limits. It is continuous if it preserves limits. So given a function from A to E, there is essentially a unique function f, a lower freak, which is co-considuous and which extends f. This function can be described easily. It's called the left-can extensions of f along y. That's a technical name. But it has a concrete description. The reason is that if you take a pre-sheep, then every pre-sheep is a co-limit of representable, but in a canonical way, this means that x is actually the co-limit over the diagram A over x. Let me write it like this. A of yA. I'm sorry. I think it's Yuneda who first observed that. Any pre-sheep is a canonical co-limit of representable. This indexing category here is the category of elements. I'm using the Yuneda lemma to identify natural transformation from the representable from yA to x because I use the same notation as a map from A to x. I write arrow from A to x where A is an object of the category A. The corresponding natural transformations are like this. By Yuneda, this is the same as an element in xA. There is a category, the category of elements of x. The objects are pair AA where A is index A, and morphism, our commutative triangle of this kind should say A is in the category A. This is a notation for this category, which Groznyczyk used a lot. The category of elements of a functor is written by Groznyczyk's element of x. A slice is A over x. It's the category of representable objects mapping to x. This is the same thing. You have this category of elements of a pre-sheep, and there is a projection from A over x to A, and you can compose with the Yuneda functor, and this is a projection, and you get a diagram of representable indexed by the category of elements of A. The category of elements of A is here, of x is here, that's here. A typical object is like that, and the value of this functor at a given element is just Y of A. You forget the structure map, so every pre-sheep is a canonical collimate of representable. It's a miracle. I think that mathematics works on a certain number of miracles, but it happens that something becomes very, very simple, and we don't really know why it is so, but it's like the complex numbers. It's very, very simple, but why is it there? I don't know, but without these simple facts, mathematics would be very hard or impossible. It's one of the Yuneda lemma, and this fact that every pre-sheep is a collimate of representable in a canonical way makes life very easy for us magnetists. Because if you want to extend continuously, or co-continuously a functor, you use this formula here, because if I have a functor, which I want to extend, so I assume that the functor preserves a collimate, so I will have the formula that if F preserves a collimate, it will be the collimate of F of Y A with A in the same diagrams. If there is a co-construed extension, it will have to be that, and F of Y A is by definition F, you see? So we see that it's the collimate. So we have a formula for extending an arbitrary functor into a co-conservative functor, and we see there that it's unique. There's a unique way to do that. So the category of pre-sheep is the free co-completion of completions under a collimate of a category. And I would like to think of this as the linearization of the category, because I want to think of Suprema as sum, and I want to think of finite limits as product. So what I'm looking here is the linearizations of a category. This is very much like taking a set and embedding it into the linearizations of it into the free Abellion group generated by it. I'm sorry. Oh, right, right, right. Thank you. Here. Okay. Okay, so we have this linearization process. Now, do we have the other process which is adding multiplication? Let's see. Remember that a ring is made in two steps. From set, you take community monoid and then rings. So we need to understand what is the first step of building the free category with finite limits. Okay. How do we build up the free category with finite limits from a given category? So in this case, it would be like cat, cat with finite limits. And then here, actually, we go with the topos. Okay. So we are going to tell you how to construct the free topos generated by a category. So at least we still don't know what the topos is. I didn't define it, but we will be able to construct the free topos. So how do we add finite limits to a category? Well, it is easier to add finite co-limits because we know how to add all co-limits. It's the unit I'm betting. This add all co-limits. So in order to add finite co-limits, you just need to take the sub-category of finitely presented perceives. Some perceives are finite co-limits of representable. So a perceive is finitely presented. Essentially, if it can be described by a co-limit co-kernel of a finite co-product of representable. So you take a finite co-product here, a finite co-product there, and you take the co-equalizer, and that's what you get there is a finitely pre-sheaf of finite presentation. Now, the category of pre-sheaf of finite presentation is actually closed under finite co-limits. It's not difficult to check. Okay. And the unit I've talked to and use something here, which you could call the unit I've talked to again, but it lands into a smaller category. And this is the free co-completion under finite co-limits of A, which means that now, that if E is finitely co-complete, co-complete under finite co-product and co-equalizer, and if you have a functor here, you will be able to extend your functor in essentially a unique way, unique up to unique azimorphism to have a triangle which commute up to canonical azimorphism. So we know how to co-complete a small category, co-complete under finite co-limits. But what about completing other finite limits? Well, one of the marvelous things about categories is that every category has an opposite, right? It's a marvelous thing. I mean, before Allen-Burr and McLean, we had very few examples of duality, you see? But since every category has an opposite, we can always change it, and it's just an amazing thing. It's very trivial, but it's a very important process. So in order to co-complete under finite limits, so you take the opposite of A, I first take the opposite of B, and then I take its finite co-completion, and then I take the opposite. And from the unidad functor, you will get the functor here, which you could call the unidad again, but which is not exactly the unidad. And this category has finite limits, and it is the three completions under finite limits. Okay, so maybe we should give it a notation. I... Jean, do you have an notation to suggest me? So I will pretend that it's like completing under joint. You see, joints are finite and fema, okay? No, meat, completing under meat, okay? It could mean big completions, right? Okay, this is bad. Okay, FLA, no? Finite limit. Not very inspiring. Okay, and which direction? This direction? Yeah, but I will put the arrow in this direction. Okay, for the finite limit completions, okay? Okay, thank you. Yes, I agree. Yeah, notations are extremely difficult, and terminology also very difficult. Grufnzik was very good to find the right notations in the right terminology. I have a lot of admiration.  Well, the three topos, I did not even tell you what is a topos and what is the category of it, but the three topos generated by A are actually the pre-shifts, so the core limit completion of the finite limit completion. I'm sorry? All pre-shifts. Yeah, there is no topology because it's free. Topology comes when you want to make a quotient. Remember that in the case of friends, the quotient friends were in projections with the nuclei. So if you want to make a quotient, you need the analog of nucleus in this context, and this is exactly what the Grufnzik topology are providing. Okay, now I should give you some axiom, the zero axioms or versions of zero axiom. Is this a monad? Yeah, with a small problem because you started with a small category and you land with a big one, and so a monad should be an endofonter, but otherwise it's a monad. Okay, yeah, I'm not finished. I did not, yeah, sure. Yeah, yeah, yeah. You see, remember that morphisms between friends are maps that preserve suprema and meet, and meet are finite and fema. So the same thing for topos, so I will define what a topos is by giving zero axiom. You could use zero definition to define what a topos is. Zero characterizes topos in a certain way, so you could define this axiom definition as a presentable category. E is a topos if the following conditions hold. So the first one would be that pullback functors are co-considutes. The second axiom is that the following square is a pullback for A and B. So if you take the co-product of two objects, A and B, and you look at the inclusion, and you take the pullback, you take the intersections of A and B into their co-product, then that's the initial object, that's zero. So this is a pullback. And three equivalence relations are effective, which means that if you have an equivalence relation, it's always the equivalence relation of a map. It's always obtained by pulling back a diagonal, if you like. Okay, that's a version of zero axiom. It's not exactly the zero axiom, but I want to make some remark. The first axiom here is distributivity. You see, the distributivity of pullback over co-limit. So, because what it says is that if you have a map from A to B and if you have a diagram now, Di mapping to B. So D is a diagram from a smaller category to E over B. So you have a family of objects over B and then you can take the co-limit of the pullback, co-limit, thank you, of the pullback. I'm sorry. Yeah, yeah, presentable category fortunately has limits. Presentable category have by definition co-limits, but they have also all limits, all limits. You see, it's the analog of this theorem, or results, elementary, that if you have a poset, which is a soup lattice, suprama, then it must have enfima. Yes, I mentioned this. And the exact analog of that is to say that the presentable category, which is actually defined as a category with co-limit, has limits also. Okay, so this is why I can write the here pullback and there will be a canonical map from this to A, the co-limit of the DI, and the condition is that this canonical map is an isomorphism. And you see that this is really a distributivity law, because for example, if the co-limit is a co-product, you see, I'm saying that this is the same thing as the co-product of A cross B over DI. Now, I'm defining topos this way. It's equivalent to the classical notion. It's a theorem, right? It's a theorem. It's not obvious completely. It's essentially a zero theorem. But that's one way of defining what a topos is. You may have a definition because there are many ways to characterize a topos. Co-consumers means preserving co-limits. No, no, no, no, no. I forget about the definitions of the geometry. This is not one. That's equivalent. That's equivalent. I cannot prove it in this talk, but this definition here is equivalent to the classical notion. That's a theorem. So we can use this one if you like. If you don't like, you can use another one. But the reason I'm putting it here is that it clearly shows that the distributivity of finite limits and co-limits plays an essential role in the notions of a topos. Now, what is a morphism, a geometric morphism? Actually, I'm working here not in the category of topos, but in the opposite category. It's a bit like working in the category of frames and in the category of locales. So I'm going to define the algebraic notions of a topos. So, or the algebra, okay. So a morphism and algebraic morphism, algebraic morphism of toposes, let's say from E to E prime. Okay. It's a functor which preserves co-limits and finite limits. That's it. No, no, no, no, no. This way, this way. An algebraic morphism, okay. So in this direction, an algebraic morphism of topos is a functor from E to E prime. It's a functor that takes... That's what you wanted to say.  It's like the category of rings. Let's say a topos, okay. And finite limits, finite limits, and arbitrary co-limits. And then there is the category of topos, okay. The category is the opposite of that, okay. So this is like here, then when we say that frame opposite are locales, okay. Is the category of locales? Well, we do the same thing here. In other words, locales are kind of fiction with respect to frames because it's just obtained by reversing things upside down, okay. Well, topos are also fiction. They are just obtained by reversing algebraic topos upside down. And these things are rings, okay. And what is the proof of that? It's the fact that the constructions I just gave of the three topos works. In other words, if you take... If you take A category with finite limits. So this is like... And then we know that this is the enveloping topos of the category with finite limits. In the sense that it has this universal property. Well, actually this is a theorem. You take the UNEDA. You have the partial category. So you start with the... Now you take a topos satisfying this condition. Take a topos satisfying these axioms, okay. Take the topos, okay. Now the topos is here. And I take a fronter that preserve finite limits. Preserve finite limits, okay. And then I know that there is a linear extension of it which is what we saw before. It's the left-hand extension, the linear extension. We extend it linearly. Just with the formula. Extend it. Linear. Theorem. This fronter is not only linear. It is multiplicative. It preserve finite limits, okay. This is, in some sense, there should be or there could be the fundamental theorem of topos theory, but I don't want to say that because it's maybe an SGA4, actually. I should check. There are so many things in SGA4 and I never read it systematically. I may have missed this book. It could be there, but really what it says is that there is a distributivity law between arbitrary core limits and finite limits. And from this distributivity law, the notions of topos, which is ear, emerge. That's essentially the idea. And the theorem here is not... I think I will try to give a proof in the notes, but you may receive the note in a couple of months. I have a lot of things to do. But this theorem is kind of interesting to prove. Let me just prove you an instance of it. Let me show you why this preserve finite product, exact. It may say a function of preserving finite limits can be said to be left exact. Okay, so I'm starting with... I'm sorry? Yes, exactly. Okay, yeah. It's a morphisms of this type. It's an algebraic morphism of topos. It's a function that preserves... Okay, so let me try to give you a quick proof of that, but it will be not complete. I will not prove that it preserves all the back. I will just prove that it preserves product. And the proof is trivia. The difficulty is to show that it preserves all the back for product is very easy. To preserve product, you want to show that f of... if x cross y, that the canonical map to f of x cross f of y is an isomorphism. You want to show that this is an isomorphism for every x and y. Okay? So let's suppose that x and y are representable. Let's look at the case where f, x, and y are representable. So in this case, you have f of y, a cross y, b, and it goes into f of y, a cross f of y, b. That's the special case. But the product of two representable... Oh, oh, oh. Yeah. I'm finished. So you want to show that this map... Okay, so in this case where you have a representable, this is y of a cross b, because since the category has finite limits, it has product, and the unit has function to preserve. So in fact, you are looking at a map like this, and this is f of a, and this is f of b, because f, our shriek, extend. So you see this is f of a cross b going into f of a cross f of b, and we're posing that f is left exact. So this map is an azimorphism in the case of representable. Okay. Now, taking product, fixing one variable, preserve co-limits. Okay. By distributivity. You see, by distributivity. So there is a diagram here, and if you use the canonical co-limit, y is a co-limit of yb, and use the fact that this is an azimorphism, you fix one variable, you play with the other, and then you can't do it simultaneously. You have to do it one at a time. It's a function of two variables, which is co-consumers in each, but not simultaneously. You have to be careful about that. And the theorem is done. The difficulty is to prove the general case. It's, you have to slice, and there are something a bit more subtle. Here you see I have used very little of the actions. Now, why is it fundamental as a result? I will be finished with that. It's just, if you have topos in the sense that I have defined with the axioms, then since it is a locally presentable category, you can always find a subcategory a, which is large enough so that the corresponding functor, just because it's locally representable, a to e, is a localization, which means that the right adjoint is fully faithful. That's just because e is, that's a general result for presentable category. You can always do that. Okay, once you have done that, what about if e is a topos? Well, in this case, you could choose a to be closed under finite limits. Okay, and then the inclusion has preserved finite limits. So the extension here, let's call that f, the inclusion, the extension f star will preserve finite limits. It will be a geometric morphisms of topos where the right adjoint, with a right adjoint is fully faithful. Well, this is exactly the other definitions of what a topos is. It's a left exact localizations of a topos. So that prove, at the same time, zero still run and etc. I guess I should stop here. Yes, thank you.


As part of Obangami Saharan Express 16, Ghanaian Visit, Board, Search and Seizure teams are conducting a series of simulated at-sea boarding exercises which will boost Ghana's antipiracy, illegal fishing and illicit trafficking capabilities.


OK, so thanks for giving me the opportunity to speak here today. And indeed, I will talk about the resource theory of superposition, which is not the resource theory of all kinds of quantum superpositions, but a special instance of it. And this is work I did in cooperation with Nathan Killaren, Dario Egloff, and Martin Blenio. So let me start with a few words concerning quantum resource theories in general. Well, as you all know, there are protocols and devices which work on the laws of quantum mechanics that outperform their classical counterparts. Now, a natural question is why. What in quantum mechanics makes this protocol more efficient than classical protocols? And one way to attack this question is in the framework of resource theories. So the most studied and most established quantum resource theory is the entanglement theory. And it's based on a restriction. All quantum resource theories are built on a restriction that is placed on top of the laws of quantum mechanics. In this case of entanglement theory, the restriction is the restriction to local operations and classical communication. And that is a physically motivated restriction because it's much easier to communicate classically because you can amplify classical information, but you cannot amplify quantum information in general. So then with this restriction, the property under study is entanglement because it cannot be created using only local operations and classical communication, but it allows for tasks which are forbidden otherwise. For example, it allows one to overcome the restriction. The simple example would be I teleport my system from one lab to the other lab, then I do whatever I want and I teleport it back. So with the use of entanglement, I've overcome the restriction to local operations. Now in general, all quantum resource theories are built like this. One puts in a additional restriction which should be modified physically. From these restrictions, there emerge two main ingredients. The first one is the three states. So these are the states that are easy to create or simple. And the second ingredient are the three operations. And the minimal restriction onto the three operations is that at least they should transform the three states into three states. Otherwise, I could create resources for free. Now in the example of entanglement theory, these are the separable states and LOCC. And then all states that are not free, we call them resource states. Now once this basic framework is set, one tries to answer questions like, how can I manipulate my resource? So can I transform one resource state into another one using only the three operations? How can I detect the resource both theoretically and in the lab with measurements? And how can I quantify the resource? So can I introduce an order or a partial order into the resource states? And all this is in mind usually with operational advantages. So one wants to use the resource in order to perform some tasks better than without the resource. And in addition, so that's basically the idea for applications. It helps to study the property by itself from a fundamental point of view. Now if one investigates these questions rigorously, then one hopefully understands the resource better. And so one can use it more efficient in new applications or one even finds out which resource is present in which application. Now let me modify the resource theory I will present to you now. So in principle, all properties of quantum mechanics that you cannot reproduce using classical physics can lead to an operational advantage. So in general, all types of non-classicality are a resource or might at least be a resource. One underlying principle of different quantum properties is the superposition principle. So in coherent theory, one studies the superposition of orthogonal basis states. In entanglement theory, one studies the superposition of separable states. And an basically optical non-classicality is the superposition of global coherent states. Now so it's very natural to investigate non-classicality in terms of superpositions. And that's exactly what was done in this paper here. Now if we want to define entanglement, there's a relatively big agreement on how we do this. But non-classicality in general is not a very well defined quantity. So one idea to quantify non-classicality like mathematically rigors is can we convert it to entanglement? So if we can convert state to an entangled state using a fixed operation, then it's a non-classical one. If we can't, then it's a classical one. And with the theory I will present you here, that's exactly possible. So we can use the theory to define non-classicality via entanglement. Now let me come to the basic framework or the mathematical framework I will use. First, we only consider finite dimensional Hilbert spaces or state spaces. And the pure free states are defined by these CIs. And these CIs, they form a linearly independent, but not necessarily orthogonal basis of the state space under consideration. So in coherent theory, these pure free states, they are orthogonal here or not. And I will tell you later why we made this choice. Now the free states in general are just the statistical mixtures of pure free states. And the free operations, they are defined using free cross operators, the cross operators Kn here. And they are constructed in a way that they map the set of free states into itself. Now then the free operations in general, they are all quantum operations that can be decomposed into these free cross operators. And they should be trace preserving. Now as in coherent theory or in most other resource series, you can define other sets of free operations. And this gives rise to other resource series. So that's not a special feature of this resource theory, and it's not a deficit. For example, in entanglement theory, one could also consider only one way classical communication. And that's for some application, a well-defined setting, which gives rise to another resource theory, but to a meaningful resource theory nevertheless. So I will not comment on alternative definitions of the free operations. I will just say why this one is a good one basically. So if we see this quantum operation as a generalized measurement with outcomes n that are associated with these cross operators Kn, then if we are allowed to sub-select according to this measurement outcomes, we can never deduce that resource states have been created out of free states. So in a sense, this is the maximum set of free operations that if we are allowed to do post-selection cannot create the resource for free. Now let me come back to the relevance of the theory. So if you want to define non-classicality using the principle of superposition, then you can use what is called a classical rank and it has been introduced in these two papers. So if we have a general set of free states, so in this case, not linearly independent, then the classical rank of a pure state is just the minimum number of free states we have to bring into superposition in order to represent the state. So in a sense, this is the analog of the Schmidt rank in bipartite entanglement. And now, having this quantity, this classical rank, we can define faithful conversion operations. So this is a physical operation that transforms all pure states with a given classical rank into an entangled state with the same Schmidt rank. The idea behind this is that we do not create entanglement out of nothing, but we rather transform the resource of non-classicality into the resource of entanglement. Now, these faithful conversions, they allow for the definition of non-classicality because we can just say now we quantify the amount of non-classicality by the amount of entanglement we can create using this fixed conversion operation. Our S is the Schmidt rank. Now, not for all set of free states such faithful conversions exist. And indeed, such faithful conversions, if we are in a finite dimensional Hilbert space and have a countable set of free states, they exist if and only if the free states, the pure free states are linearly independent. So that's why I made at the beginning a choice of linear independent free states. Now, these faithful conversions, we will see later what an example for these conversions is. So in addition, the theory here is a generalization of coherent theory. So coherent theory is the same theory where the free states are orthogonal. And in a sense, this allows us from a conceptual point of view to study the importance of orthogonality versus linear independence in such theories. Well, now for a precise example where we can use the theory is in quantum optical non-classicality. So if we have a finite number of global coherent states, then we can use the theory to study the non-classicality in their super positions because a finite set of optical coherent states is linear independent, but they are not orthogonal. And in this case, the faithful conversion operation can be done using a simple beam splitter where the second input port is in vacuum. So this would be a conversion operation which is really easy to implement in the lab. And maybe most important, this research theory here can be seen as a starting point for more general research theories and I will comment on this later. Okay, I hope I've motivated the work. Now we have defined the three operations. We are the three cross-operators and we would like to characterize them explicitly. In order to do this, we can use the method or the idea of retzy-broken states or vectors which you might know from unambiguous state discrimination. So these are just, since our set of free states is linear independent, we can always define another set of states which are orthogonal to all states but to one. So in 2D real space, we have our two free states and then we can always find states like this. So C1 orthogonal is orthogonal to C2 and this projection onto C1 is one. So they are not really states, but rather vectors because they are not normalized, but yeah. Now if we have these vectors at hand, we can write down the explicit form of the three cross-operators. So these are all cross-operators that have this form, where the fn of k, this is just a function that gives me an index and the Ck and they are complex valued coefficients. Now, another question which is very important if one deals with trace decreasing or trace non-preserving quantum operations is whether we can complete a map which is trace decreasing for free. So for example, if we have a map that we can decompose into three cross-operators but which is not trace-preserving, then we should naturally ask ourselves, well, if we want to implement it physically, we always have an operation which is in total trace-preserving and if we cannot implement the missing part for free, then we shouldn't really call it free because it's just then neglecting the part in which we do something non-free, which we cannot do in the lab. No, it's not valid for every resource theory. So in this theory here, we can whatever trace decreasing map, so it doesn't even have to be decomposable into three cross-operators, we can find three cross-operators that complete it for free. But in entanglement theory, that's not possible because there's the problem of uncompletable matrix product bases, so that's not possible in general. Here it is. And as I already said, that's important if you want to work with trace-decreasing operations, and it was also an open question in coherent theory, but since coherent theory is basically a special case of this theory, where your free states are orthogonal, then that's also valid there. Now, if we want to compare the superposition in different states, we want to put a number on them and say, well, if the number associated with one state is higher than the number associated with another state, we have more superposition. And as an other resource theory, we do this by so-called measures, so this is a function that maps quantum states to the positive real numbers, and it's a measure if it satisfies certain axioms, on which you can also argue, and I will present you one set of axioms, which is motivated physically, as it should always be. So the first axiom is that it should be faithful. So the measure should be zero on all free states, and it should be non-zero on non-free states. So this is really, we have separated our state space into two parts, and now we want basically our measure to represent the separation. Then the second property is that our, well, as we heard in entanglement theory, our measure should be monotonic under the free operations. So if we take a state, act with a free operation on it, then the amount of resource in the output should be at least, well, it shouldn't be, it should be larger or equal to the amount of resource in the input state. Now, the case of monotonicity under selective free measurements on average is basically we do a free operation, we do sub-selection according to the outcomes, and then on average, we shouldn't be allowed to use this method to increase the amount of resource we have. And the fourth condition, which is convexity, basically states if we mix two states, we do not want to use this, to be able to use this procedure to create resource states. Now, if we have properties three and four together, this implies property two, and there are useful measures or functions that only satisfy some of these properties, and for specific applications, they might be useful as well, so that's why I've kept this point two of monotonicity under the free operations. One measure that satisfies all these axioms is what we call the one measure of superposition, and if we have a quantum state, we can always decompose it into its free basis. Since they are linear independent, but form a basis, such a decomposition is always possible, and if we then add up the absolute value of all kinds of off-diagonal elements, then this is a function that satisfies all four axioms I've presented to you before. And the advantage of this measure is that it has a closed form, so there are other measures, but usually they include some minimization, some maximization, and since this is closed, we can calculate it for qubits explicitly, so if we have the free states, which are depicted by this line of the arrow, then the one measure is low in the blue area and high in the red area, so the further we go away from these free states, the more superposition we have. As an all-resource series, an important question is, if we have one-resource states and we use only the free operations, can we transform the state into another resource state or, in general, into another state? Can we do this terministically or if not, can we do it at least with a probability P and if yes, what's the highest probability to do so? Now, first question is, okay, when are probabilistic transformations possible at all? And the answer is in this classical rank, so the number of states we need to bring into a superposition of free states, and whenever the classical rank of the initial state is larger or equal than the classical rank of the final state, then at least a probabilistic transformation is possible and if not, then the probability is strictly zero. Now, if such a probabilistic transformation is possible, we would like to know, well, what's the highest probability P? And the answer to this question is given by the solution of a semi-definite program, so we need to maximize the probability under some constraints and the FNs here, these are cross operators, they are known and they depend on the initial and the final state and using such a description in terms of a semi-definite program is useful because we know how to attack those problems numerically and there are also loads of analytical results concerning the treatment of these problems. Now, for qubits, with the help of the semi-definite program, we can analyze the maximum probability of transforming one state to another one. Again, we have the free states depicted by this tiny line here and our initial state is denoted by this line here and here, so it's the same image just from different points of views and if we take this initial state, then in this color scheme here and the block sphere is encoded, the maximum probability of transforming it to, for example, this state, it's close to one, to this state here it's, the probability is, well, about one half and as you can already see, it's not, at least in the block sphere, it's not really easy to see first to which state we can transform it with certainty and then how we can estimate the probability of maximum transformation probability. If we have one state which we can transform with certainty into all other states, then it's the most useful state, so it's the state with maximum superposition because we can use it for all applications, for all protocols. And so it's often called a golden unit and in the case of qubits, such a state always exists, so if we have again our two pure free states here and here and their overlap A, then the state with maximum superposition is the one on the block sphere which is the furthest away from the set of free states. So this state here, we can use only free operations and transform it into all other qubit states. For higher dimensions, this isn't generally not a case. In the limit of coherent theory, such states exist, but here not. And now I want to give you a rough idea of how we can prove this because it basically uses everything I've talked about so far. So it exists out of two steps. So first we find certain candidates, so states which might in principle be maximally non, or states with maximum superposition and then we show that none of these states indeed can be used to create all other states with certainty. And to do this, we just build a count example in 3D. So we choose a basis, a classic basis or three free states and then we notice, well, if they want to be states with maximum superposition, they have to maximize all possible measures because they cannot increase another free operations. And so in addition, we've already seen that a classical rank can never increase. So we need states that have maximal classical rank and amongst these states, we want the ones which maximize the one measure of superposition. And if one chooses the basis with an asymmetry, one can do this relatively easily analytically and ends up only with a few candidate states. And then one just uses the semi-definite program to show that these candidate states, they cannot be transformed to certain other states with certainty. And this can be done analytically because for the semi-definite programs, we have the property of duality. So we can transform them into another problem, bound to solution of this problem and then we have also bound on the initial problem. Okay, now if we have this resource, what can we do with it? So does access to the resource really grant us with an additional power or with additional possibilities? And indeed, if we have access to the resource, we can overcome the restriction. So if we have a unitary, an arbitrary unitary that acts on qubits for simplicity, then, well, we have for every input state, we act on it like a unitary, a qubit unitary and this is basically equivalent or we can reproduce this operation using only a free operation, Psi, that acts on two qubits. And what it does, it acts on the target qubit on which we want to apply the unitary. And in addition, it acts on another qubit state which is in a maximum superposition state. And the output is separable and we have applied the unitary on our target qubit and we have basically destroyed the superposition in our auxiliary qubit. So we've used the resource, we have consumed it in order to overcome the restriction. And it's maybe important to emphasize that for a given unitary, this Psi here is independent of the input state. So it's really reproduced the operation and we do not only reproduce the action of the operation on a certain state. In addition, we can use superposition as a resource in decision tasks. So decision tasks are, as we heard yesterday, a part of quantum etiology and we can, well, basically describe it as a quantum game and something similar has been done in the case of coherence in this paper. So we have two players, Alice and Bob. Alice might or is allowed to send a quantum state to Bob who applies a quantum operation on the state. And this operation is a selective measurements with D plus one outputs. If the output is zero, then he just says, well, please give me another state. So he asks for a new turn. However, if the output is not zero, he returns the output state of his quantum operation to Alice. Now, the goal of Alice is to guess N. So she wants to find out, basically decide which output N Bob received. And in order to do this, she's allowed to do an arbitrary quantum operation on the state. Now, she has two possibilities. For example, she might do unambiguous state discrimination in order to find out which N Bob obtained. Well, if this fails, then she has the ability to just ask for a new turn. So she can hand in another state, a new state and try again. However, she can also make a guess. And if she's correct, she wins. If she's wrong, she loses. Now, if we use a certain quantum operation here, so a free quantum operation, then for N not equal zero, what the operation does is it basically imprints a phase which is dependent on N onto the free states. In the case of N equal to zero, this failed and Bob asks for a new turn. Now, if Alice has only access to free states here, then she cannot win the game in the limit of large D because the output row N is independent of N. So whatever free state Alice puts in, row N is the same for all N. And if, well, in the limit of large D, we have, and in addition, the probability of output N is the same for all N. So the best thing Alice can do is make a random guess. And if, well, if we have a high enough dimensional Hilbert space, the probability of making the right guess goes to zero. However, if she has access to certain superposition states, these output states are different. And in addition, they are linear independence. So she can do indeed an ambiguous state discrimination when it fails. So when she gets an indecisive answer, she just tries again. And if she gets an decisive answer, well, she can guess with certainty. So she can give the correct answer for sure and thus win the game. So access to the superposition states basically turns certain loss into certain win. Now let me come to my conclusions. So I hope I have convinced you about the relevance of this research theory. So we can use it to define the a bit vague definition of non-classicality using entanglement. Then it's a generalization of coherent theory. And most importantly, it's a step towards a quantification of optical non-classicality. So we've spoken a bit about the mathematical structures, for example, of the three maps and the completion of three maps. I've introduced to you the concept of superposition measures and we've spoken about superposition manipulation in the form of a semi-definite program. And we've investigated states with maximum superposition. And we also noticed that there are advantages in superposition in having access to superposition states. Now, of course, that's far from being completed the theory. So we haven't said anything about mixed state transformations. And what is also very interesting concept is the concept of approximate transformations. So we want to transform an initial state, not exactly to a target state, but only approximately to this target state. Also, we have only considered transformations in the asymptotic limit. No, we have not considered transformations in the asymptotic limit. So we have only focused on single copy transformations. So I have only one copy of the initial state and not access to other copies. Well, and all this state transformations, it would be very nice to find a closed condition when we can transform one pure state into another pure state with certainty. Because at the moment, that's still the solution of a semi-definite program which you have to solve. Well, as an other resource series, or especially in a resource series of coherence, we can combine this restriction with further restriction. So one can think about local superposition-free operations. So for example, if I have some specially separated labs, I should in a sense include the idea of spatial separation and of classical operations on the systems in the lab itself. And for mesoscopic or macroscopic systems, one would also like to include energy conservation, for example. But the most important next step in my opinion is that one works on generalizations of the series. So it's still very restricted because we have linear independence, we are in finer dimensional systems. And if one would like to quantify optical non-classicality, then one has to go to infinite dimensional Hilbert space. Probably one would like to choose for the free states the global coherent states because they are most classical. And they are continuous. So they are not only not linear independence, but they are also not countable, which makes the series more difficult. But if one manages this generalizations, I would say this is a step towards maybe a full description of optical non-classicality and that's what we are working on in the moment. So thanks for your attention and I guess we have time for a few quick questions.