So last time we talked about this assignment, if you start with a scheme S locally, almost a finite type, you attach to it this category of incoherent sheaves. So in fact this, so the reason this was invented, first of all, this was invented simultaneously or quasi-simultaneously, but many different groups for different reasons. And so, and the way I came across it was not because of Langlands. So I didn't know that this was fix the problem in Langlands correspondence. My reasons were different and I'm going to explain what they were. So the reasons are the following. So yesterday, I mean, no, yes, last week we said that if you have amorphism X to Y, there is a nicely behaved functor of direct image in this context. Direct image, yes. And so you don't need properness? No, it's direct image and it's defined. We gave a kind of a definition, namely you take an object of co, you regarded as an object of quasi-co, you move it, apply the usual direct image and then you notice, aha, it actually is in D plus and therefore it can be lifted to inco, that was the formula. So it's designed so that this diagram commutes where I remind that psi was this natural functor going from inco to quasi-co. You embed co into quasi-coherent sheaves and then you extend. So this functor is nice if you behave nicely with it. If you start doing something not good, it will betray you. Namely, so remember that in the eventually co-connective case, there was also a left adjoint. So if you embed quasi-coherent sheaves into coherent sheaves and this upward looking diagram will not commute. So nice functor, but be careful with it. Okay, but in addition to pullbacks, to push forward, one actually wants to have pullbacks. So if f is proper, you want to create this adjoint pair, so proper. And of course, you can do it within quasi-coherent sheaves, but something bad will happen. So f of Pashrik, so let me write it. Let me write just usual quasi-coherent sheaves. So this is the usual direct image and this is its right adjoint. It exists for some general reasons, however, so however is what's called not continuous. And I remind you what continuous means. So continuous means that does not commute with infinite direct sums. So there is no problem on D plus, I suppose. Pardon me? On D plus it is on D bigger than or equal to something. Yeah, but D plus is not closed under direct sums. Yeah, okay, you take D bigger than or equal to something. Yeah, but I don't want to do that, I want to do the whole thing. And then, so let me tell you why it doesn't commute with direct sums, infinite direct sums. So namely, we have the following lemma, I actually stated one half of it already. Suppose we have a pair of adjoint functors, f and g, as usual, one that's above is the left adjoint, and I'm always in the world of categories with arbitrary direct sums. So if g is continuous, let me say it like this, we said it already, then f sends compacts to compacts. And b, if c is compactly generated, this is if and only if. And so in this situation, it's easy to see that if you have a proper map, there is no reason that it would send compact guys named the perfect guys in x to perfect guys in y. Take the inclusion of a singular point in y, and then you'll get the image of a skyscraper will not be perfect. But the question of, you can limit the category in some way, and no, but what is the point with respect to the original problem of the geometric long-lance? So let's see if you take a curve of jnus at least two. So this is impossible to have a less general, maybe less complete statement by bounding categories on both sides. It's impossible because this functor is of even in arbitrary genus, the Langlans equivalence is a unbounded, yeah, it's of unbounded amplitude, yeah, well, at least one in the bad side. So if you take the constant sheaf on bungee, it will go on the spectral side to something which is goes infinitely to the left to D minus. So therefore you don't want to cut D minus because you will lose one of the main players. You lose the constant sheaf. So you don't want to do that. So for that reason, we want to work with categories, well, these big categories. Okay, so therefore this will not be continuous, but in the analogous situation here, so again the right adjoint will exist for tautological reasons, and it will be continuous because of point B of the lemma. So now let me say a few words. Why do I insist so much on having continuous functors? Why do I care? So there are two reasons. One is very practical and the other is even more practical. So why continuous functors? So answer one is that if the functor discontinues, it's very difficult to compute anything. So namely, so say it's your functor and suppose C is generated by a bunch of objects. That means that every other object can be obtained as an iteration of procedures of taking direct sums and cones. If your functor is continuous, so you have the algorithm of how to extend, if you know what your functor does on the given collection of objects, you know how to extend it everywhere. Well, just because I have control, yes, it's manageable. If the functor discontinues, if I know what my functor does in the generating set, I really cannot say much. And also, I suppose there are some, I'm not sure, but in usual algebraic geometry, the functor, of course, is like in modern times, where it has many problems, in particular, obvious ones, like you can restrict two opens and you get the same upper shake and I suppose when you do this infinite thing, you can lose some of the trivial effects, like if you can restrict an open on the source or on the thing. That's still fine. These things are still fine. We'll get there, actually, in a second. So let me just say that have more control. But here is kind of, well, maybe a better reason. So you can consider this world of DG categories and continuous functors. So the main observation is that these guys can be tensored up. So this is actually a symmetric monoidal category. So if you have C and D, you can create their tensor product, which is another category of the same kind. So let me give an example. So if C is A modules, where A is associated with algebra and D is B modules, then C tensor D will be A tensor B modules. Again, I'm talking about all modules. And so it turns out that this operation of tensor product gives you a lot of power. So you can do a lot of things and later on in today's talk we'll see some of these things. So for example, typical example, if you have an algebra object inside this, i.e., it's associated algebra within this monoidal category, if you have a left module and a right module, you can tensor them up over A and get yet another category. So this gives you a power to produce a lot of new categories. Sometimes construction that, well, in this case you knew what you wanted to get will be A tensor B modules, but sometimes you don't have an explicit formula. And some categories that you wanted to exist will exist because of this thing. This is an operation which is well-defined, though. Yes, it's well-defined. So I'm saying that this category has a symmetric monoidal structure. And it's really functorial only with respect to continuous maps. If you have C1 mapping to C2, then C1 tensor D will map to C2 tensor D if the functor from C1 to C2 was continuous. It will not map if the functor was discontinuous. And what is the tensor over A? Same thing. So this is a monoidal category. If you have an algebra object, if you have a left module and a right module, you just may attempt to take the tensor product. It's a well-defined operation in a monoidal category. If you're- So A is a kind of an algorithm. Yeah, A is, so it's an algebra object inside the DG cat continuous. Well, Aka, monoidal category, monoidal DG category. So, and if I were asked to define what I mean by a monoidal DG category, I will refer to Luri's definition of this tensor product. I will say it's an algebra object in this monoidal category. So monoidal DG categories are algebra objects in here. Algebra object in the monoidal category of DG categories. But when you say monoidal category, it's not in the very old sense of usual category. No, no, I'm saying that this is a monoidal category because of this operation. No, but you see, there is an old sense of monoidal category. It's one utility monoidal category. Yes, it's, yeah, it's, we live in an infinity world. Yes. Can I see it? Yeah. In some model, for a little question. Well, in the infinity world, and then again there, yes. Sorry, what's the link with content function? So the operation of tensor product is only functorial with respect to continuous functions. If you have C1 to C2, you will not be able to tensor of this morphism unless your function was continuous. Okay, so going back to this, so we still want to define, if you have a map, we want to define f up a shriek from int co x, int co y to int co x. Well, in the following way, so you want that if f is an open embedding, you want f up a shriek to be the left adjoint of the functorial direct image.  And in general, I mean, when you want to attempt the construction, of course, what you will do, by Nagata, you will factor your morphism like so.  And you know what they are in each case. And of course, you can't do this in infinite setting. I mean, you just can't define functors but say, okay, just choose a factorization. There is infinite number of homotopic consistencies that you have to check. Yet, you can set up a machinery using these factorizations. You can organize a big, big thing and make it work. So, this has actually been done in the world of constructible sheaves, so there's two papers by Yifeng Liu and, I'm forgetting his first name, Wei Zhenzhen. So, they did it. They constructed this f up a shriek. So, it is a functor. You're taking schemes, almost a finite type. It's a functor to dig a cat. Yes, so, yeah, according to my conventions, I don't even say that they're derived. So, I'm currently writing a book with Nick Rosenblum, where we'll give a larger framework for this construction. So, I'll be very happy if you ask me a question about this, but maybe in question time. So, in this way, this looks like a construction, but in fact, you can state and prove of the existence of uniqueness theorem. So, it won't be some arbitrary thing. So, you can make a statement that such a functor exists and is unique given some more structure. And again, I'll be very happy to talk about it, but not in the kind of main time of the lecture. All right, so now I want to go a few more steps in this direction. So, we know what up a shriek is on schemes. So, then I claim that we can actually extend it automatically to pre-stacks. So, let me be slightly technical. So, I'll talk about pre-stacks that are called locally almost a finite type, left. So, and these are, by definition, these are contra variant functors. I'm taking a fine derived schemes that are what we call eventually co-connective. They have finitely many co-homologies. And these are arbitrary functors from this to group oids. So, these are before we define just pre-stacks to be arbitrary functors from all affine schemes to group oids. And here I'm considering these guys, I just didn't want to lie. So, I'm giving this formal definition. So, these left pre-stacks are actually full subcategory among all pre-stacks. So, there is a fully faithful embedding. However, it's not either a right adjoint or left adjoint anything. So, it takes little thoughts to say what it is. And again, I would be happy to say it, but again in question time. Just, you don't need it for this lecture, but I want to say that this notion, this notion are connected. So, I'll now extend int co to a functor from all, from schemes to pre-stacks to djcat. So, and it'll be the same procedure as how we extended quasi-co from schemes to stacks. Namely, so int co of a pre-stack y will be the limit over, well, it's the same procedure, int co of s. So, now we can talk about int co on pre-stacks. So, let me give an example. It'll be a test of alertness to see if you guys are asleep. So, for example, I'll say the d-modules on the scheme x are int co. So, last time we introduced to any scheme we introduced x deram. It was a pre-stack, such that, so let me remind that home from s to x deram was by definition home from s reduced to x. So, this is a pre-stack, and I'll say that d-modules on x are by definition int co of that. Arbitrary. Are people happy or not? What? Yeah, we're supposed to be, is this supposed to get tested when we're awake or is that coming? No, no, no, it's supposed, it's already tested if you're awake or not. Yeah, so this is already supposed to provoke some reaction. So, let me give you, so let me say what should have aroused your suspicions. So, last week we gave a different definition of d-module. So, this is today, yes, last week we gave a different definition. We said that it's quasi co. Okay, so you can ask what's going on? Why am I changing from here to here? You can ask, are they the same actually? Or of what? Okay, so let me explain what's going on here. So, there are two more pieces of data. So, note that on an affine scheme, if you consider perfect complexes, this is a monoidal category, you can tensor them up, and you can tensor coherent sheaves by perfect sheaves. Yeah, just tensor up. And you can extend it and you'll have an action of this monoidal category on this category. And the way the definitions work for quasi co for int co, the same will be true that on any pre-stack quasi co will act on int co. This is on the one hand. On the other hand, so if you have any scheme or stack, there is a, oops sorry, there is a canonical map to the point, and you define the dualizing to be the pullback, of course. And so using these two pieces of structure, you define a functor, I'll call it Upsilon, for any y, it's a functor that goes from quasi co of y to int co of y, namely action on the dualizing, f maps to f tensor omega y. So for any pre-stack, you have a map from quasi co to int co, and the theorem is that if y is Durham of anything for any pre-stack, well, within our finite type world, then this Upsilon is an equivalence. So what is omega? Up a shriek from the point. We now have the formalism, so we can up a shriek. And so y is any... So y is obtained from a completely arbitrary pre-stack by taking Durham. So the Durham is smooth. Durham is smooth, let me put it like this. And if y is a scheme, then Upsilon y is an equivalence if and only if the scheme is smooth. So for schemes, this Upsilon is an equivalence only for smooth guys, but the Durham thing is smooth. Smooth means classical and smooth. So y is a derived scheme, and this functor will be an equivalence only if and only if y is classical and smooth in the usual sense. And so just a moment about the upper shriek. So you said that you can define it for... Any morphism. Any pre-stacks. So I've extended... So I had my functor defined on schemes, and then what I do is technically... So I gave a formula what intco is on a pre-stack, but this formula has a name. It's called the right con extension. I extend from schemes to pre-stacks in some automatic way and I obtain a functor from pre-stacks to DG categories. Yes, yes? Relative to... Shriek. Yeah, everything with shriek pull back. No, because if you have a morphism, because I understand that... I'll explain. The shriek don't pull back, right? Okay, I think I understand your question, I'll explain. So I think here's what Oprah is protesting against. This has nothing to do with pre-stacks. You can ask this question about schemes. So say we have a morphism of schemes, and then you have the following guys. There is quasi-co of x. There is quasi-co of y. There is intco of x. And there is intco of y. And then there are the following operations. Here, there is a usual star pullback. Here, there is this function, epsilon, tensoring up by the dualizing. Here, there is an epsilon for y, and here is the shriek pullback. The claim is that this diagram commutes. Intco y. So the shriek is the final intco of... Schemes, but then by extension, any pre-stacks. But when you take the derived kind of inverse limit of intco s, this means that if you have s-prime going to s, you are using the final intco s to intco s-prime, which is the usual pullback. Which is the after shriek. Yeah, it's the up-a-shriek that I said that I erased this blackboard. I said that up-a-shriek is, by the work of Liu and Zheng, up-a-shriek is defined as a functor from the category opposite of a fine scheme's almost a finite type to digit categories. No, but this was for the lattice sheeps. No, no. So they did it for lattice sheeps, but the same construction works for intco. Okay, so the lim is not relative to... Up-a-shriek. But it seems that when you define in previous lectures what was intco, it was lim. I don't remember now. Correct, and I'll comment in a second. So it's another notion of intco. No, they are equivalent. I'll explain it in a moment. So that's where we're going in a second. If y is a regular smooth scheme, so what are the two categories? Not derived, something less simple. So what is a statement? What does it mean? I'll explain it in a moment. Let me just do it right now. Is it omega? Yeah, omega is what you think it is. So let's recall what happened. So that's another moment to test your awakeness. So let's live in the world of schemes. I just said that if you have a scheme x, you have the sphunkter omega x from quasi-co to intco. So this is the sphunkter and it's tensoring by the dualizing. It should arouse in you in the sense that we are in a zoo. So do you know what I mean? Well, I claim that we already had a bunch of functions between these two categories before. So what we said that always you have this sphunkter in this direction and if x was eventually co-connected, you also had a sphunkter that I call xi. And here I come and I say that in addition to all of this, you also have this sphunkter. And what is going on? Well, indeed, you have all of these guys and so, well, you have all of these guys and they're different sphunkters. Okay, but what are they? Okay, so the simple example is the zephyne line. Example, if x is smooth, so then let me say that these... Well, the way we set up intco, it will be just the same as quasi-co. There is no difference. So xi x equals omega is the identity sphunkter. Nothing is going on. In this case, this sphunkter is tensoring up by the dualizing line, y, by the canonical bundle. Shifted to the line. Canonical bundle... Shifted, so it's the dualizing. Shifted to the minus the dimension of x. So, Ofer actually asked another question. He detected a discrepancy in how I set up intco in the case of algebraic stacks. Let me suppress that for a moment because it'll take me too far afield. Again, it'll be a question that I'll be very happy to answer kind of in question time. So, we have only zoo. And let me just say that it's only this sphunkter that actually makes sense for arbitrary pre-stacks. So, these guys are actually a feature of schemes and it's this guy that extends to arbitrary pre-stacks. So, this is the more fundamental of the more fundamental sphunkter. And here I stated in the theorem that this sphunkter is an equivalence on anything which is deram. But if x is a locally complete intersection scheme, I mean defined by Gwendolyn and Schwan, then it's already interesting. Yes. So, in this case, and yes, and actually I should have said this. Okay. So, we have these two categories and now there are two functions. There's this xi and there is the epsilon. And you can ask how are they different? And they differ by tensoring by a line bundle. So, if it's locally complete intersection, this dualizing still makes sense. It's a line and these are two functions from one category to another and they are not the same, but they differ by tensoring by a line. So, that's how it looks like. We just asked this. So, the deram is a pre-stack. Yes. But is it ever anything else? Are there any conditions under which it's... No. It's never represented. No. It's cotangent complex is zero. So, on any pre-stack you can talk about the cotangent complex and for anything which is deram this cotangent complex is zero. Because the cotangent complex is tested by mapping infinitesimal thickenings to your stack and deram is set up in such a way that doesn't feel any nilpotent. So, to define the cotangent complex on the stack this is a very general kind of stack. Yeah. So, cotangent complex is defined in the way we talked about in the first lecture. You're taking this square zero extensions and you're mapping. And you... Yes, thank you. Because this condition is not sufficient. The project is zero. It is. Yeah. All right. Isn't deram of these things what we get? Deram of deram. Deram of deram is deram. Yeah, because zero is a deram. Okay. So, let me just summarize what just happened. What just happened was a crash course on Upper Shriek. So, now I'm coming back to the notion of singular support and I want to comment on how it behaves with respect to Upper Shriek. Again, the reason I want to do it, again, because we're looking at this diagram, loxis parabolic, loxis for the levy, loxis for G. This is... We call this P spectral. This is Q spectral. And our Eisenstein functor, I spectral, was the composition of Q-spec Upper Shriek. And last time I said that we'll have to talk about it and now we have it with P-spec int-co lower star. And what I wanted to explain is that this functor maps the category, so it maps int-co nilp on loxis M to int-co nilp loxis G. What we did explain last time was the following. We did a half of it. We introduced, so int-co nilp on loxis P, and explained that the direct image maps it to int-co nilp loxis G. Today, I want to explain the second part. I want to explain that Q-spec Upper Shriek maps int-co nilp loxis M to int-co nilp loxis P. Just the other half of what I did last time. Okay, let me first remind you where this came from. It's a general assertion. It's not specific to int-cos. It's something general about singular support. So, reminder. So let X to Y be a map between quasi-smooth schemes. So then we have this functor of int-co direct image on the one hand and also we have this correspondence. I will go from sin Y over Y. It maps to sin X and projects down to sin Y. And I call this map sin of F. So the theorem from last time was the following. So fix n sub X inside sin of X and n of Y inside sin of Y. that If you take the singular Co-differential the sync of f take the pre-image of Nx it would be will be contained in NY so in this case the claim was that This direct image maps intco Nx on x to intco NY on y So it maps this subcategory to this subcategory. That was the theorem from last time So now I want to state the corresponding result For a pashrik, so Let me ask some student Who will volunteer the theorem for me so so same circumstances Nx and xy so when Does f up a shriek send intco and y y to Intco no apple up a shriek Okay, so Pierre wants to give an answer, please Give me so it has to do with the singular No, give me the answer it happens. In fact, it will be for no leave, but give me sufficient condition Transfer cells it will be some other place you'll see we'll gather in a second just in one minute. It's not transversality. It's containment It's an estimate from above. So anybody yeah some x should contain some Yeah, we want this to be small as compared to this Like the bigger n-axis the easier is for this to hold. So what's your estimate that's that's to Smooth schemes Yes, there will be something there will there is a parallel assertion about demodules, right you can estimate the characteristic variety of Upstairs in terms of the downstairs. So give me the analogous thing here. So what if you have a demodule downstairs if you want its Singular support of its pullback to be contained somewhere. What's your condition? No, no, no transversal containment Transversal will be in the moment Yeah, it's the same thing in the opposite direction so theorem So this happens when provided that containment Just in the opposite direction that and why Why is small enough as compared to an X ie? Something is contained inverse image something else if sing F of This is contained in an X same condition just inverted containment and It's an exercise Apply it to the morphism Q and obtain this containment deduce From theorem But here we wanted more so we wanted this functor eyes not only to respect single supports. We actually wanted To send coherent things to coherent things. We wanted to preserve compactness For this piece back lower star it happens because the morphism was proper Now we are doing this kilo upper shriek enough upper shriek will not in general pervert preserve Coherence you're doing up a shriek Like if you have a singular variety and a point mapping to it. I if you do up a shriek Well, you'll get all the X's there'll be there'll be infinitely many of them So it's not doesn't preserve coherence so So you can you may want in these circumstances ask so when is F upper shriek of F coherent if F was coherent and this is Well Pierre was saying transversality this will be transversality So we can actually give a criterion when coherence would preserve in terms of singular support Map map between quasi smooth schemes pardon No This is what you're saying is too weak.  Let me Do something more general well after all up a shriek is a Version of tensor product. Let me just say something more general for tensor products.  So then the following are equivalent So one is that if you take the usual tensor product, of course derived one is coherent. I Mean coherent means it has finally many cohomologies B You can take their shriek tensor product By this I mean so what's tensor product? It's upper star under the diagonal map of the external tensor product This will be upper shriek Is coherent then it will be Internal home In either direction It's coherent D Internal home in the opposite direction is coherent Shriek you take F1 times F2 on X times X and you shriek pull back with respect to the diagonal map And of course, this is all boring, but all of it is equivalent to the following Namely you take the singular support of F1 It's a subset inside sing you take the singular support of F2 it's a sub thing inside sing you intersect and you want it to be zero section Now for for a map between Usual schemes, you know if it is local complete intersections and or even finite all dimension Anyways, then the F upper shriek sense could bound current about yes Now in your context, let us say if you have usual Complete intersections, of course the map between there is not necessarily complete. Exactly. So your condition In this case Is not it's it's non-trivial So you didn't state exactly the condition. So I said I stated something more general instead of taking up a pullback, I talked about tensor product of Sheaves so you can this pullback can be expressed in terms of the tensor product Pullback Shriek pullback can be expressed in terms of this kind of tensor product and store pullback can be expressed in terms of this Kind of tensor product on something else on something else. I'm currently I'm blanking on what I think on x times on x times y or something like this On x times y because you Yeah, so you will be You'll be doing F tensor The structure sheaf You'll be tensoring with the with the structure sheaf of the diagonal something like that I was speaking to the diagonal something like that So I'm saying that if you know this you can give a criterion for when coherence is preserved There is there is there is sergility. Yes Yes Yes, it's isomorphic to Df1 tensor of those Yes, yes, that's what I'm saying that if you want if you talk about that for Pashik you you'll be using point B of the theorem But not the structure sheaf, but the dualizing. Yes For for quasi smooth. It doesn't matter because the dualizing is a line bundle And then the singular support that you are you will be using is on x cross y Yes But because the other thing is is just the dualizing its singular support will be zero time to single support of the original thing But now when you have usual schemes You could use your singular support was using the fact that it is quite a smooth That it uses that for usual schemes. There is no there is no What is the singular support for usual Computer section, it's the same as you regard the usual computer section as derived one and You create its its sing and it is upset there Usual case is a particular case of this So maybe let me maybe it'll easy if I just give it if they write the formula so so You know what I'll write this formula. I don't want to do it while I'm standing I'll do it during the break So I said that you can give a criterion Deduced this criterion from here. I'll do it, but let me not do it. Just standing up. All right Okay, so This is well These two theorems are kind of basic basic functoriality properties of in of singular support So that's how they behave with respect to push forwards and pull backs All right, so But your Eisenstein thing so if I take g equal g and 2 The the ball is a borel. So I'm is a torus. So I take a local Unlock the sink of the torus. So it's not so complicated. I take the punctual sheath at some point. Yes, what is the image? You asked this question before Yeah, but I at least on on an open subset an open sub something of Loxy And the curve is of genius bigger than two. So there is a irreducible local system Let me understand the question again. So you take the nicest open subset that you like Do you prefer of Loxys lock system of G? Okay, so we want to do the computation. So you're starting with Sigma It's a point in Loxys T Loxys T torus. Yeah a particular point skyscraper Okay, let's be careful So in our category nilp is zero for the torus, right? So this is actually in quasi co Loxys T ie in co nilp But that was zero Okay, we start with this and then we do Eisenstein and You're restricted to a nice. Yeah, so and this is this is an object of int co Loxys G It's a particular object there. So So let's ask a question about it. So what kind of question would you like to ask? So there is a very interesting question that one can ask But okay, so I'll let you ask a question. So we get we get a well-defined object So Yes Yeah, it's a sub stack. Yes indeed. So and it's easy to say what it is It's either the local system is reducible or when it is reducible This two one dimensional guys are non isomorphic. This is open subset on that open sub stack This int co nilp is just quasi co and then what what you get is what you think you'll get So it'll be just direct image Well, I mean there can't be anything because you're just dealing with the usual quasi co but on the interesting subset where nilp is not zero you're getting some phenomenon and You asked this question before so No, no, you asked a bunch of years ago with this there was this mystery of Eisenstein and it's that's where it lies and it's exactly It's mystery of Eisenstein has to do with remember I wrote this treacherous diagram that one diagram did not commute it It has to do with that All right, so you take the constant She from all on Luxus why nux of T Again so There will be phenomenon so it's The open part where nilp is zero you got you will not get anything interesting, but then something will happen Okay, so I Think I should make a break. So let me just say what I had in mind for the last hour There are two themes that I wanted to cover and I think realistically only I will only have time for one of them So, let me just Say what these are So theme number one is the following So we said that if F is a Into coherent sheaf you can assign to it as its singular support of F which is a subset It's really it's really a subset. There's no scheme theoretic structure, but you can ask is there a scheme theoretic structure Can you do something slightly better? So and let let me tell you what kind what kind of better thing one can do so Let me consider an object not an intco, but I'll make quotient intco by quasi-co. It's called the category of singularities So in general if you have a I'll denote this with a circle. So it's intco Modulo quasi-co So well by the same and now it's well the same principle to it You can attach an object in the projectivization of the sing Both remember so we had this adjunction so So you can think of this quotient as either the kernel of this functor or The quotient by the image of this functor. It's the same and the image This is fully faithful You can take this and modulo the image of this functor or it's the same as the kernel of that functor Perfect complex and some And So quasi-co gets supported on the zero section therefore if you take an object of the quotient It will have a well-defined support on the projectivization So let me say to this you can assign let me say singular support with the circle of F Which is a subset in this projectivization but so What you do have you have more so here you have not exactly scheme theoretic structure, but you have the following piece of structure So it will be the following theorem that you consider the category of D modules on This projectivization and this category. It's a monoidal category And now we remember what I talked about in the beginning. So it's a monoidal category in the world of DJ categories As such it will act on this category of singularities So not only do you have it's a dumb dead-way singular support something act on something and so and This is actually of central technical importance for full england's and I can explain that so It kind of it's a central result that allows you to do things So this is theme number one and theme number two is the following It has to do with local language So local language is still very highly conjectural. We don't unlike Global language. We don't have a statement, but we kind of know what it's supposed to be So it's supposed to compare the following so global language was an equivalence of a Pair of categories this category was supposed to be equivalent to this one Local angles is supposed to be an equivalence between a pair of two categories This two categories supposed to be equivalent to these two category So what are they one is? categories equipped With an action of the loop group Yes, yes, I mean it's a DG categories equipped with pieces pieces of structure When I say category I mean DG category So these guys together form a two category an infinity two category The totality of these forms an infinity two category No, no, no, no, no, it's different the word to means that I allow non-invertible two morphisms There is there is book in the in the process What Yeah, you know Lurie did infinity one categories and these guys are infinity two categories Yeah, so This Maybe not so bad Okay, so this is the geometric side and here it will be categories Well, let me say it again Don't understand it technically yet sheaves of categories over Local systems with respect to language dual group on the formal puncture disc and Again, it's a mess. So I've been working for many years trying to make sense of what it is but even if I Am able to make sense of it what it is this cannot hold For the same reason as the global guy was wrong Namely here. There is more stuff than here. So there are there's a phenomenon Whitaker degeneracy index G-check Langlund's dual Yeah, I look so let me just If I'll go in either this direction of this direction the next hour and then I will explain whatever I can explain So but what I want to mention is that even man managed to do this It's still wrong because we have to account for the same phenomenon In the global case. We had to replace quasi co Of locks sis. We have to make this replacement of int co nilp So we enlarge the spectral side and then it had a chance to be Equivalent to the geometric side. So here so sheaves of categories over a pre-stack You can think of it as some kind of categorical to categorical quasi co So then we should be able to also somehow enlarge it To some version in categorical and the only problem is that no one knows how to do it So in the case of quasi co you said, okay, just take coherent sheaves in complete and that's your guy Here it's just completely not clear in complete. It's just completely not clear So see this is a two category and then you're enlarging this two category and the worst is that Let's just relax for a moment So I'm sure you guys have seen two categories in your lives But all the two categories that I've seen are of the following sort. It's a cat Each two category has the following shape. It's a it consists of categories equipped with an extra with extra structure its categories with With extra structure So any two category that I've seen in my life comes equipped with a forgetful functor to the two category of categories Well, if you can think of any other, please let me know but I haven't seen one So see we've seen categories that are not equipped with natural functor to sets So that's why I was so so Yeah, we know categories that are not sets with extra structure like sheaves on the manifold. It's not set with extra structure. It's more and plenty of other examples No, I don't even if I did it will be the same problem. Yeah, okay, but I can do it But I mean it's so these are my dad Yeah, these are technical problems of this but even if I resolved all of these it will still be not enough for the following reason that I'm creating a two category without and this cat this big two category is really doesn't have a forgetful functor to To the two category of categories If you take a simple level Like you already level or something you can expect that you know the answer I know the point of view of local long-run. Yes All I want to say is that there are two options for the next hour and I would like to know which ones of which one would you like to meet to go to? No Which one is supposed to be in the first week Okay, so We can take a vote and then I can do in question time. I can do the other There is this kind of at T Okay, let's let's take a vote who wants one The first Okay, who wants to seems like there is there's parity So, okay, let's take five minutes. So one is It's content of another paper with a rink in it's called the category of singularities and global Springer fibers Okay, so I Said that I'll talk about the following the demodules on the singular the projectivization of the sing act on The category of singularities, but I will start not from here. I will I'll motivate it by language. So I'll say what problem we were solving and then how that kid that thing came up So let me remind you Something that I stated at the end of last time So we said that you take all this spectral Eisenstein series functors and You apply them to quasi-co Don't even do the modification. So this quasi-co sits inside in co you get some collection of objects inside in co nil and see what these guys generate so the theorem Was that what they generate is exactly in co nil of loxious G Okay, now, let's take a look what it means what it means to generate Suppose as usual you have a pair of our giant funkers F and G So the lemma is that the image of F Generates G Including M equal to G the bulk So the image of that generates D if and on if the functor G is conservative conservative in the world of DG categories means just it doesn't send anything to zero Pardon except zero But so you can imagine that to prove something this conservativity would not be enough So kind of what we want to do we won't turn this kind of statement That some functor G is actually fully faithful. So this is So D will be This in co so we want to map this category fully faithfully into something has to do with quasi-co's button parabolic's and So that is this is what this is where we are going So, okay now a scary creature will appear So don't be afraid Okay, say have a morphism F from X to Y. I want to talk about So who remembers what how do we define D modules on X? But what on X the rum in co quasi-co Yeah, so either and it doesn't it doesn't matter, but say I want to define relative D modules I want kind of quasi-coherent sheaves or in coherent sheaves I don't know on X with a connection along the fibers. How do you define that? Okay, give me the definition So vertical D modules on X with respect to the map are We'll then figure out if you want quasi-co interco. Give me the geometry. It'll be sheaves on what But what could I do to fix the fiber but the fiber is nasty you can think like you can take a point mapping to Y Yes So you're considering this creature X the rum over Y the rum with Y So this kind of thing Okay, now, what do you want to consider quasi-co in co? well The claim is the actually want to consider both Yeah, so you see if X will equal to Y. This is just X so and We know that there is canonical map this Upsilon and Well, you can show that in this case, it's a fully faithful embedding But what happens is that the category that we actually interested in is in between it is genuinely in between and neither nor so note that there is a map from here and From why to this thing For the moment not but soon it will be sorry, there's a map from X to here so therefore there is Now we'll so that's why I talked about the streak pullbacks And that's why I preferred theme one because we're gonna use what we talked what we developed by the streak pullbacks so Shriek pullback defines a map from here to into co X Shriek pullback with respect to this map kind of think of it forgetting the connection Forget relatively module suggest all modules. Now, let's assume that X and Y are quasi smooth again. I assume X and Y are quasi smooth in this case there is well Also known as quasi coherent sheaves on X Things with zero single of support and let's define This as the pre-image So these are those objects here such that they forget the connection They have zero single support and it's fairly easy to see that the image of this functor actually Lies in here. So there is quasi code. There is intco and there is something in between and It turns out I'll say in the explain the moment that this is the beast we're interested in And let me give it a name because it's too much notation. Let me call it. I X over Y Okay, and so what we're gonna do We're gonna consider this morphism locks his P to locks his G and We are interested I claim in this fellow so you can ask Why are we interested in this fellow and not in some other fellow? The reason is that so we are still trying to prove Langlans and Well, what you want to do you want to translate things from the spectral side to the geometric side And it turns out that this guy if you assume Langlans well If you assume induction this guy can be translated to the Well can be fully faithfully embedded into something explicit on the geometric side so let me just say that By induction on semi-simple rank this category Fully faithfully embeds Into what's known The p degenerate Whitaker category You don't have to understand what this p degenerate Whitaker category is. I'm just saying this because to explain why I'm interested in this category Okay, so these are my building blocks and So, let me state the theorem and then I'll explain Its meaning so the theorem will look as follows It will say that a certain functor from ind co nil on locks his G To well, I want to take them all of them together and I'll write the following symbol. I'll rate right glue This Categories where P runs through the whole set of parabolic of G So the theorem is that is fully faithful. So what I have to explain is that What do I mean by this glue and what is the functor? So well So it's kind of easy to see that For the left a joint what The essential what's generated by the central image of this is the same as what's generated by these guys So the generation is the same, but I'm getting something fully faithful and so this theorem is central to Langlund's because Yes, this is what I'll explain On the geometric side for GLN we have an analogous embedding of D of bungee on to glue Well, we have a map in general glue and will be this With degenerate Whitaker guys So we have a functor in general. It's known to be fully faithful embedding for GLM and If you believe what I said you'll get a fully faithful functor in one direction So that's kind of that's the the mechanics of the proof of the proof of Langlund's So that's why we're interested in this assertion So you Yeah, I will I will not be talking about the geometric side. I'm saying I'm just giving motivation Why I'm interested in this kind of assertion. I'm interested in assertion because I have a parallel assertion On the geometric side, I have a functor Between these categories which I can prove that is fully faithful. That's what I mentioned by Induction on a semi-simple rank and then I can show that if I on the generators if I go this way The generators are in the image of this functor and this gives me a functor in this direction Which is automatically fully faithful. So this this is this is how the proof of Langlund's for GLM goes No, no, no, not at all. No, this is our Langlund's right. We're trying to compare this and this If I put Langlund's dual So we're trying to prove that this category is equivalent to this What I'm trying to do I'm trying to construct the functor in one direction and moreover one that is fully faithful and The way I'm doing it. I'm embedding both into some larger categories and I'm constructing a fully faithful functor between this larger categories but then I Still have to construct these functors Finally, it'll be an equivalent finally it'll be an equivalence, but I mean you there are various stages of the proof and this stage will show that The functor is actually fully faithful Jill to there'll be two pieces. I have to say what glue is in a moment You've been insisting that Well, it's well, it's not of course, it's not boring When you say you have a map on this on the right side That means that for P equal G you are able to do something for P equals G What will happen is that I'm dealing with quasi co and so Quasical G. Well, okay, let me just say it again all these are scary words. I'm not What happens it goes to embeds fully faithfully into the run version of Representation to G check and this is the Whitaker category. So it's a run. It's a run version. So you're putting again, so I don't want to it's a It's a category in Run is the person Zivran The student Okay, yeah, so so I'm asking I'm answering Lamont's question why this is what is useful because I mean this this embeds into something local Yeah, so the way you do it you you can exhibit generators you mean this oh so this is completely geometric So you then you Produce this collection Representation yes, this these are the Whitaker coefficients So there is a functor of Whitaker model that takes goes from here. It's a paper dedicated to you So it's Yeah, yeah, I know So It was just a motivation why I wanted this theorem So let me just maybe let me just go ahead with this. Of course this language story is very interesting, but Okay, I will just to remove the temptation. Let me erase this Okay, so what is glue? So here's the setting for glue Say you have some index category a and you have a functor from a to DJ cat So to objects of a you have some DJ category c and you have when you have an arrow from a to b You have functors. Let me call them f a to b So in this case, there are a couple of things you can do one is something will been doing all along You can take the limit So this is a category whose objects you should think of as follows. These are objects little c a for every a and For every arrow You you're given isomorphisms. So the limit is just really kind of a compatible system of objects in each of your categories But there's also another thing. It's called lax limit and I'll explain give an example in a moment This is also collections of objects like this But now we no longer require isomorphisms. We only require maps in one direction in this case this direction and There are two there's lax limit and the co-lax limit Yes, this is what you meant to say yes, it will be and this is what I call glue and Alex well, yes, that's people also So and let me let me give an example exactly Maxim's example what I mean by glue So consider the following example say a is this category. It has two objects zero and one and one arrow and consider the following example of this C a's let y be a topological space and Y zero being open and Y one will be a complimentary closed So C zero will be Sheaves on Y zero again, I mean derived category C one will be sheaves on Y one and the functor zero to one will be I up a shriek J low a shriek. So then I claim that this glue Sheaves Why I will be sheaves on Y itself So all I'm saying the sheaves on Y are glued in precisely in this sense In term from sheaves on the strata. It's not a limit. It's the lax limit. So So this is what I mean by the right-hand side Yes, and then it will be arrows in the opposite direction It'll be co-lax. I wrote this example because I wanted the arrow in this direction Yes No, no, no, there's no shift, but it's as as written but I'm when a I'm doing derived categories Functors is the functor is as written You take all the parabolic I'm take all the power. Oh, no Postset of standard parabolic's conjugates standards conjugates a class with parabolic's Yeah, it's a finite post set. All right, so This is what I take so This is what I mean by glue. Let me say what this functor is So if you look at the definition of what it means to glue what I have to do have to produce a family of functors loxious G to these categories that are not Compatible under pullbacks, but they are lax compatible. So I don't need if I go from one parabolic to another I won't don't want the functors to strictly compose. I want I need them to compose up to up to natural transformation So, let me say what these functors are So the functor is the following. I go from int co nil loxious G I Even forget that it was nil I embedded into the whole thing then I do up a shriek to int co loxious loxious P the rom over loxious G the rom loxious G oops Problem I've gotten here. I wanted to land in a subcategory. What do I do? No, I landed. No, I'm not here. I'm here. I really land here What do I do a Joint so so and then a joint What's called I? loxious P over loxious G So if I didn't have the a joints, I will land in the strict limit, but because I have these adjoints Strictnesses broken and I only have natural transformations. So these are my functors and the theorem says that this this The functor into the group category is a fully faithful embedding Okay, so in the remaining 15 minutes, I'll try to explain the Why what I said about D modules helps to prove this theorem Oh, it it exists, it's the right adjoint it automatically exists by general Louis stuff And moreover is it continues because this fungus sense compacts to compacts This embedding Yeah, and it's all of these categories a compact generated Yeah, so there is a map from here the stack maps to why Yeah, yeah the projection just pull back right adjoint right adjoint left adjoint does not exist You said that sometimes you have a joint and both so this is right adjoint It is continuous because the initial functor sense compacts to compacts okay, so I'd like to explain not the proof, but the idea of the proof of this theorem and That idea is the following so I Mentioned the following theorem that there is a canonical action of D mod Projectivization, I mean let's say sing Fly on intco with a circle Why which is by definition the cat what's called the category of singularities and again here So now I'm gonna use what I said before that this procedure of tensoring up So here are the features In terms of this action I can say I can express the singular support So for that M be a closed subset Inside this projectivization Well, I can take Intco with the circle with supports in M On why so before to a subset in sing itself We attach the subcategory, but now I'm taking a subset in the projectivization And this subcategory will live in the category of singularities So this category turns out to be we can express it in terms of this action. Namely you take The entire guy And you tensor over D mod on the projectivization with D mod on M So there is a restriction map from m sits inside this projectivization There is a restriction map tensor up and you recover what the category with given supports is This is point a of the theorem and Point B of the theorem pertains to that situation when we have not just y but x over y You leave that for a second So let me also introduce the notation I not X over y It will be I X over y where I kill the boring part. I kill the quasi-code part So point B says the following So that this category I not can also be expressed So again, it now will be a question to the audience So it will be intco Of y Over D mod of the same thing Sing why with what can you guess? So it's the difference between This and this it's a claim. It's also gotten by this procedure of tensoring This procedure tensor product with something So let me say that it's D mod projectivization of Something so I want you to guess what this what that something is We put it on so okay. I'll just call it. It's not contingent. Let me call it relative sing So let me say what it is. Okay. Pierre is well equipped to answer this question. So Let's look at our picture again. So we have y to x It maps to sing y it maps to sing x and Here, let's take the kernel. Let me call that Y over x it's the guys here that die So this is what I want to put here So this is a map to fiber-wise linear map and I'm taking its kernel I eat so I'm taking the pre-image of the zero section. Oh, sorry. It's x over y so This is what this category looks like so I want to say How this kind of thing helps to prove the theorem written on the blackboard? Well, you prove it in several stages first It's quite easy to see that It's enough to prove to mod out everything by quasi-co. So it's really Enough to prove this Why It's the co-differential like if you like look usual differential geometry in usual differential geometry have co-tangent of y times co-tangent of y over y with x Have this diagram Which should be familiar this is the just derived version Okay, so I want to explain how this kind of thing helps to prove this kind of thing So so now if you look at the left-hand sides, what you'll see is that so now Both sides are obtained from intco Luxus G by tensoring over so Luxus over D mod sing Luxus G with something I'm in all cases. I'm killing the quasi-co and that's what the circle signifies So a claim in this Both sides are obtained With something so let me explain what these some things are so on the one hand we have this projectivization of nilp, so we have D mod on the projectivization of nilp and here it'll be the category glued from the following things Will be it'll be projectivizations of the relative things relative things on Luxus P Luxus G So D modules on that So we've replaced the original statement that some functor that has to do with intco About a functor that only has to do with D modules The advantage of the letter is the latter statement is topological so It's the statement is that certain homotopy types are have trivial homology Let me say very explicitly so so The latter statement is that Yeah It is supposed to be no to The fully fatefulness is that certain Homotopy types have trivial homology and in the remaining five minutes, I'll say what these homotopy types are Groups yes, now we'll see Usual sense No, nothing it just homotopy types as we know them So and else let me say very precisely what they are So fix a point a comma sigma in nilp So Sigma is a local system for G so Sigma G is a point in Luxus G and a it's a section Durham section of the adjoint So nilpotent and the morphism So now let P a be a parabolic to it you attach the following scheme Which are called global springer fiber because you have the following things it'll be Reductions Sigma P of Sigma G to P such that this a Belongs not just to be the parabolic it belongs to the unipotent radical and So they then you can form a homotopy type by gluing them and there is a so these reductions Let me call it and the claim is that this homotopy type So so We don't know if it's the homotopy type is contractible we know the homology is trivial Yes, so there will be a diagram of spaces In this case the diagram will be in this case the diagram will be strict Yes, you take the column call limit homotopy call limit to call limit It's some it's some sorts of push-outs True yes, yes, yes Homology of a call limit is the call limit of homologies. So this It's not a great idea to do it because the way Kind of an object was a point in each plus morphism between images a kind of a pass So this looks like doing homotopy limit not calling But now you all do the same with now that there's a homotopy call limit instead. Oh, I don't understand that analogy because You see so this what I call lacks limit you can equally call it lacks call limit so this So a limit really has a universal property for mapping in and call limit has a universal property for mapping out So lacks limits and call limits. They have lacks universal properties and they have both So you have a lacks limit You can say what it takes to map out of it is the same way as what it takes to map into it It's just the same natural transformations So when you talk about lacks things in this context, I could have called these guys just the same way lacks call limits categorical definition It's not you love the call you usually call it of a category Junction of objects and then filled with morphisms. Yeah, it's a relation and and and so and limit is obtained by families for every and so What you Can maybe after yes. Yes, I can well I'll so I don't want to kind of keep people but I mean I'll tell you exactly which homotopy type it is And the end of the day this homotype homotopy type is very Well, it's no no, it's not something that we had seen before but we But at the end of the day after gluing so we certainly conjecture this homotopy type at the end is trivial We proved its homological triviality so you glue a bunch of Springer fibers for different parabolic see glue in them some way and the claim is that at the end of the day No, so what what is involved is the following so you have a springer fiber Let me say it like this so you have a datum of a local system datum of a local system you can think of a curve It's just a bunch of a homomorphism from from the fundamental group to To G so then How should I say it so if you have a so the springer fibers I'm talking about are the intersection of the springer the springer fibers, you know it Plus the fixed point locus for these endomorphism acting on the flag variety So it's these kind of things so the curve only appears via its fundamental group namely the fixed point loci of of the generators on the Oh Yeah, this part is just you take a strict diagram of topological spaces The maps that are involved are not in bedding So you have to when you're taking this co-limit you have taken the homotopy co-limit because this But the claim is if you take the homotopy co-limit at the end you'll get we conjecture. It's a point We haven't proved it but For each you'll to this kind of thing for you to is a triviality but well Well after we massaged it up to here it became a triviality When we got so there is stuff, but it has to do with all these theorems about Action of demodules kind of this is a non-triviality for g2 But this kind of statement already when you're down to parabolic because you only have two parabolic it becomes very very easy For g3, okay, I'm tempted to say what the diagram looks like for g3. It looks as follows so you consider the flag variety the complete flag variety for g3 and then you'll see something like 2p1's meeting at a point and this diagram will look as follows. It'll be The post that will be will look like this zero going to one going to two And it will be a one map that collapses one component to a point It'll be another map that collapsed the other component to the point when they glue them together You left only with the point. It's something like something like that so it's Again, I didn't want to be very precise here. I just want to say how The statement allows you to go from intercoherent sheaves to actually topology and then you attack the problem in topology Explicitly using a building or something. I think my time is up


You can find us online at rcdashcast.com. You can find the links to the blogs, the Twitters, the entire back catalog of every single episode we have ever done in which we now have more than 100. Once again, I have here Jeff Squires from Cisco Systems and one of the authors of OpenMPI. Jeff, thanks a lot for your time. Hey Brock, it's always good to do another podcast. We've been a little slack recently, so good to get back in the groove here. We got this one up today. We got a few more queued up, but it's getting into the busy season for HPC. Yeah, so we have a supercomputing coming up in November. So we're at the very end of September here. So we're only about a month away from supercomputing, a little more than that. I will be there. University of Michigan will be having its joint booth with Michigan State University again this year. I will be floating around there and floating around other places. Jeff, Cisco always has a booth. Yeah, we have a booth. Unfortunately, I have a fairly terrible position on the floor this year due to some silliness, but we'll be there. I got my normal open MPI State of the Union boff with George Basilica, my co-host, another one of the open MPI core developers. Also helping out with a libfabric tutorial. Libfabric is the new up-and-coming low-level network API. We got that on, I believe it's Sunday. It might be Monday. I'm afraid I don't remember offhand. But yeah, those are the big things that I'm doing at supercomputing this year. What else you got going on? So what we've got going on is we will be announcing a couple of interesting things that we got going on at Michigan, that you can come by and talk to us about at our booth. We have our new Institute for Data-Driven Computational Physics, which we recently got funded to create. But the big, big thing that's going on is the new Data Science Initiative coming out of the University of Michigan. This is gonna be really the kickoff event for the Michigan Institute for Data Science. We're gonna be creating a graduate program, which we already have students enrolled for the fall. And the university is investing about $100 million and we're gonna create 35 new faculty positions. We've put into a bunch of medium and big data infrastructure, which is really kind of stretching the sorts of things that we've traditionally done here at Michigan, and we're really excited about some of the things we can do. We're already getting our health system lined up for health data. We've got transportation data. We've got all sorts of crazy things going on. We're gonna try to bring it all together and look at finally filters for all this data. So come by and talk to us about that. $100 million. Right, it's real money, real money. All right, well, what are we talking about today? So today we're gonna be talking about something that I know actually very little about and I hope to get some clarification about my understanding of this. We'll be talking with a researcher who's created a piece of software called Conduit. So why don't we have our guests go ahead and introduce themselves. Yes, hi, so I'm Cyrus Harrison from Lawrence Livermore Lab, and I'm known primarily for my work on Visit, which is an open source visualization tool, but today I'm here to talk to you about Conduit, which is a smaller effort we've been working on for the last few years. So can you give us an idea of what Conduit is? All right, so Conduit's something we've been looking at to sort of simplify our daily life and data exchange between simulation codes as a whole. So people who write big, big physics simulation codes, they usually have to deal with IO and deal with mesh aware IO, for example. And there's a lot of pain in dealing with static APIs and things of that nature. So Conduit was designed to sort of tug at that and make things a little bit easier with respect to passing data to and from, say a visualization tool or in a simulation code. So this was a little bit confusing when I was reading through stuff. A name like Conduit almost sounds like it's a communication or some sort of networking thing, but then you talk about, you know, describing data structures and stuff and you talk about communicating between other things.  Does it, is it one? Is it the other? Is it both? It's both. So at its core, at its core, Conduit is really just about describing hierarchical data. So the best way to think about it is sort of if you cross, you know, JSON, JavaScript object notation with NumPy. So NumPy has been used very successfully in the scientific community, the scientific Python community for describing arrays and operations on arrays and JSON's been used for dealing with hierarchical data structures and all kinds of data exchange on the web. So at its core, Conduit's about describing things in core, so in your memory, and then on top of that, you can build services like communication or IO or serialization. All right, due to unforeseen technical difficulties, apparently the internet fell apart in California. So we had to call Cyrus back in on a regular old POTS phone and we will now return you to your interview already in progress. Okay, so, Cyrus, you said something a second ago that confused me a little bit. You said, you talked about how static APIs were bad and assuming that is in contrast to dynamic APIs. Could you explain that a little bit further? Yeah, so I guess in a lot of other areas like web development or even in scripting languages, people are used to having a lot of flexibility with how they describe data, how they pass things around. And in HBC, typically, we have a lot of preexisting APIs for say describing what a mesh is or something like that or we try to solve the problem with code generation. So we're building a big code, we have code generation that describes our complicated objects. And the problem with code generation is that, well, it gives you good performance. It becomes software engineering-wise pretty burdensome. So if you look at a tool like Visit, if we were to accept code-generated stuff from all the different codes that we want to read in to visualize, it would be really unbearable, an unbearable process to get all their code and coordinate their own code generation schemes. So when we're talking about this stuff here, we're really not talking about how static and dynamic are mortal enemies or just different benefits to doing a dynamic approach. And by dynamic here, I really mean runtime. So you can do full description, run time and have introspection and things like that. So can you give us a little bit more history about how this came about? Was this trying to solve the needs of a specific code or in that code, visit or some scientific code or is this just a general problem you keep running into? Yeah, so it started out with some of the pain points with describing, so with Visit, we deal with mesh data and we use VTK for example for describing our meshes. There's a lot of other things though that go along with it that are a little bit more complicated like in a distributed domain parallel context, how those meshes on all the processors connect to each other, for example. This is hierarchical nature, hierarchical data by nature. And we have different kind of, probably 10 different mechanisms for doing this in Visit and some of them use packed binary data from specific codes and some of them use APIs that were specifically designed to deal with this but then we'd find, oh no, we have one corner case that kind of undermines our whole API. So what we're trying to do is we're trying to let the simulation code describe this data structure to us and have enough introspection so when it gets to Visit that we can actually pull out the pieces and get what we care about and what we need. And that's where it started out and it's also an important aspect of trying to deal with sort of in situ visualization where it's easier to pass things zero copy like a mesh zero copy from another code. So a lot of jargon there. So I'll let you taste me down on those things. So you keep mentioning this is really for a tool like Visit to be able to kind of figure everything out on its own. I don't necessarily want to go all the way to saying self-describing but it sounds pretty similar to that. Is this already in Visit today? Like is there a version of this in Visit today? So it's not released in Visit yet but what we've done, so over the last, so again this project started in 2013 and actually over the last year, we had a set of students from Harvey Mudd College working on it with us where we used it to re-plumb aspects of different simulation mini-apps. So these are common proxy applications that are used in procurement instead of just regular benchmarks. So what we did is we actually, it was pretty interesting we went in and had the students kind of re-plumb the IO or re-plumb the MPI and re-plumb from connecting your collecting performance data from the simulations all just using conduit which is kind of a simple building block. So we did these experimentations and that gave us the confidence that hey, this is gonna work well. So now we're starting to figure out how to roll it out in Visit and solve the specific problems of the code we were looking at starting a couple years ago and then also expanded out to be used for lots more things I think. Well let me ask you then about, Brock was just asking you about self-describing and you were talking about the APIs describing them the data itself and so on. These are also terms that are typically bandied about in the current hot-sexy of unstructured data and big data and things like that. Is this related to that at all? Cause you've also been describing this in a hierarchical type of description which implies more regularity that you could potentially use a much smaller description to describe a huge amount of data. Is this the same kind of playing field? So I think it could be. I think the focus we really had though here was on numeric types. So that's why I talk about JSON cross with NumPy, right? So we do, we could describe things in the big data realm as well but the important thing for us here is to make sure that we have a double, if we have a double array we wanna make sure we know it's 64 bits and we know the right Indianness and all these other things. So there's kind of extra special sauce that's specifically for scientific computing. So this is kind of interesting because I feel like when I first started learning HDF-5 and then later on Adios it seems like it already does a lot of these things. So what's the real difference between these two systems? Yeah, so conduit's simpler than both of those things and it's specifically built for data description in core and then other things are built on top of it. So it's not actually at its core in IO library. So it won't be dealing, for instance it could be used with Adios, basically Adios or HDF-5 could be used behind the scenes to do some IO functionality but it's really for in core. So if you wanted to pass between in situ basically between one part of a simulation, another part of a simulation or a simulation, a visualization package this gives you a very simple way to do that. And that's sort of where the line's drawn. Now there's obviously a lot of the same concepts are involved with hierarchical nature and keys and all these things but at its core conduit's about describing things as they already are in memory. So now you mentioned that JSON is used as well or JSON or whatever the, however the kids pronounce it these days. Is that used when you do, you're passing from point A to point B so like if you have a one gigabyte array of doubles you pass it in a JSON format or do you pass the description in JSON and then pass like just a native array of doubles? Yeah so this description would be passed in JSON and so JSON allows you a really easy way to describe the data in core and then basically we have a schema that it doesn't always hold everything in JSON but from going from point A to point B you would create a JSON schema that does the description and you could send the binary data separately for example. So does this, I'm trying to think about so do you allocate your arrays using new conduit array and I'm trying to figure out exactly how I would work this into my application or if this is something I kind of write afterwards almost like XDMF or something like that where I kind of write it afterwards so someone can understand something I wrote someplace else or is this actually in my application being passed around all the time? So it would be, it could sort of be both I guess that's a non-answer but the way you can use it is there's two ways. So if you already have data in your application that's basically described through the basic set of types again think numpy like floating point arrays or integers or strings. You can create this conduit object that just describes the data that already exists and owns nothing. So a conduit object doesn't own anything but a description of it which is nice because that allows you to zero copy data but it also has a dynamic API where you can just build kind of trees of, trees of hierarchical data on the fly and just sort of through the magic of some, especially in C++ some overloading you can really easily build up these data structures and have your own copy of them I guess. Once you have it sort of codified into a conduit object and this hierarchy then the use of them really looks exactly the same I guess. So this sounds relatively similar to the MPI data type concept and I see that you have some conduits that speak to MPI types of entities. Do you, is there a mapping between the JSON data types that you create and MPI data types or optional data types mapping if you're talking to an MPI entity? So we've talked about this a little bit. It's something that we would do in the future but we haven't got there yet. So for MPI operations now, basically we know how the data is described and we know how it's laid out in course so we can do serialization. So we do serialization for our MPI features currently but we could do a more robust coupling with the MPI data types in the future. So what kind of data types do you handle? So the MPI data types are both great and terrible at the same time in that they can represent anything and that's both good and bad because there's a couple of shortcuts for describing simple things but when you wanna describe complex things, you can but it takes a little bit of work to do that. How does one describe data in conduit? Is it an easy thing? Is it a hard thing? What's the interface like? Does it just figure it out via introspection? How does that work? So fundamentally it's meant to be very easy and it's meant to sort of limit the data model but basically there's three different things you can have. So you can have an object which is really an associative array so that's how you get some hierarchy. So that object would contain names of other things like a pressure field or something like that. You can have a list which is just a linear ordered non-named thing so just a blob of a whole bunch of heterogeneous things or you can have a leaf type which is one of these concrete arrays. So it could be an array of floating point numbers, it could be a robust string and there's different striding swizzles and stuff like that on those in order to allow you to basically if you're doing structs of arrays or arrays of structs of tricks you can play with how you do the indexing to make it all look nice. But if you're just dynamically creating an object you can just go and use almost like a, it's basically like an associative array or a dictionary syntax even in C++ so you can just give it a name and you assign it a value and it'll figure out the right type for you and then there's some more special sauce for dealing with complicated arrays if you have striding and things like that. So I wanna think about something like using external libraries like BLAST libraries or FFTW or something like that and say sometimes have special things like well we know this is going to be symmetric so I'm only gonna return half the data. Can I describe things like that so that it knows that it's symmetric or is that kind of not really the intended use of this? So it's not meant to solve some of those higher level problems. It's meant to just solve sort of things in core but that said you can go a long way with having this hierarchical notion to give a lot of context for things. You can I guess describe things starting at any offset you want to as well. So there could be a way if you envision that it only returns half an array or returns a pointer somewhere strange from an offset in the beginning of where you started you could do that. You could encode that in a conduit node and just return that back and it would have a description to where that started and how to access it all. All right, so if I'm using a conduit in my application should I really be describing every single of my data structures using a conduit describer object or whatever you're calling them or should I really only be doing it for the things I plan to either communicate to another application to do something like in situ virtualization or to do IO to disk with to be able to again describe it to another application. It's really about portability of data structures between applications and not within an application. Yeah, I think the fundamental focus is really between applications. There's, it's nice to have all of your data self-described but there's gonna be a performance penalty from doing that, right? So this is sort of about coupling. It's about getting data from A to B with context. Now, if it's for talking between applications does that necessarily always mean that there is a disk in between or can other flavors of IPC be used? Oh, no, definitely not. So I mean, the easiest way to talk in between applications would be the library, right? So that's actually like an in-situ visualization use case. Now, why is that different from just passing a pointer? Well, again, it's the context. So it's easy for you to pass a pointer from one library to another but this gives you a little bit more context. So as simple as passing an array from one part of your code to another that could be the case. The difference here is the context. So if two quotes of those code are sufficiently complicated then you might wanna have some context between them. There's also, you could use MPI to send things, right? IO doesn't have to be part of the picture. All right, now, it doesn't have to be part of the picture. Can it be part of the picture? Can you write conduits out to files and then read them back from files? Yes, yes, you certainly can. So right now it just has a basic capability which saves out a schema and saves out a kind of a binary representation and has some experimental capabilities for writing actually mesh aware data out to silo which is a library we have here at Livermore. In the future, we're probably gonna deal with putting HDF-5, kind of having a fundamental IO capability that uses HDF-5 on the backend in order to get things out in a better, more performant way. Okay, so you have your own format and you're also looking at using some other underlined formats but there's some things where there's these file per process and you have to describe everything back or there's methods like MPIO or some other types where you can kind of have something that's a little bit easier for human to manage, a single file for a large partitioned type problem across processors but has other issues involved with it. So does conduit favor one of these or does conduit not care or does conduit not even bother with it? So I guess it doesn't care at a fundamental level but one thing it will make easier, I think, is the sort of in the middle case which is where you're not doing one giant file or not doing one file per process but you wanna be able to collate some data sort of hierarchically and get it out to a file system. So using many processes per file, I guess and I think Mark Miller from the Visit and Silo team has a multiple, I forget what it's called, there's a term for this, right? But because it can do things with MPI and because it can serialize and help you serialize and things that helps you get data around so it'll help you be able to make choices like, well, I wanna collect this data together and maintain context. That's something it can help out with but it's not going to fundamentally pick, you must do one file per process or you must do MPI IO, one file, one giant file. It's not gonna fundamentally try to take a stand there, I guess, I'll try to avoid controversy. So what languages are supported here by Conduit? You mentioned NumPy, so are we talking primarily Python? So it's actually, it's all developed in C++ and C++ is the kind of where all the features come from so it's underpinned by C++ but there's also a fledgling C API, a Fortran API and there's a Python MPI as well. So the goal is to have sort of, it also helps you solve this sort of language confusion issue where you have to, again, a lot of times you have to do a lot of code generation for multiple languages. But since we're describing things in core with this kind of hierarchical model, the APIs are pretty sane and all of these different, they look very, very similar. Modulo, syntactic sugar, C++ probably and Python look the best but the C and the Fortran APIs are actually pretty usable for doing this stuff. So that's another goal of the project is to try to have, once you have these things described make it easy to use in these different languages. Well, I think you get a gold star, sir, for being probably the first person on the planet to mix Fortran and JSON. So I had to learn Fortran to do this project. So I avoided it up to this point but actually it's been very, very, very good. So some of our simulation codes, obviously Fortran's immensely important for HPC and we had some success of coupling a Fortran mini app in order to do some in-situ visualization stuff and that was a big win because they were looking at this API customers and saying, yeah, this is actually usable. So it was good. All right, take a quick cut here, break. I sincerely hope you are using strongly type definitions because I hate to admit that I know quite a bit about Fortran now because of my MPI stuff but the newer modern like Fortran 08 is actually even stronger types than C++ and you can do some actually really nice things with it. And I hope you guys are going that direction rather than like the MPIF.h totally implicit specification of everything kind of stuff. If you want, I'd be happy to talk to you about it in five or 10 minutes when we're done. So we're actually, we're using ISOC bindings to do a lot of what's working here. But I guess- That is good. Yeah, so that- On the Fortran interface side though, I hope it's all explicit and all that kind of good stuff. I think I might be committing some sense there so I won't lie. But again, this is, so it's sort of one data model for all these languages and it's a limited data model. So I think people can use it without shooting themselves in the foot. All right, well, let's chat after recording because I think Brock probably want to shoot himself in the head if we talk anymore. Okay, so you said this started getting developed only, what was it, two years ago? So is the API of Stables is something that like we just really start, if we have somebody's needs where we want to be able to pass between applications, maybe do some in-situ work, coupling standalone applications together, is this something we should go ahead and start using? So I think, so the core conduit library itself is pretty fleshed out in terms of functionality. The C++ API in particular, we're still filling out the Fortran APIs and still filling out the C APIs. There's a couple of other things that are new in there. For instance, like the conduit MPI and some of the IO stuff, which isn't fully fleshed out. So I don't think that would be ready for primetime yet. But I think the ideas and kind of the basic library are ripe for using now. So actually, I had another idea that came up during this. So you talked about using MPI to communicate and it doesn't have to be a file to communicate between stuff. What are some of the things that, does conduit worry about any of that communication stuff for when you have, like say you have Visit running with LibSim over here. Well, maybe that's a bad example, because that's specifically you're working on. But say I have standalone visualization application running over here and I've got my simulation running over here. Does conduit allow for that kind of like pause, expose data and it's available via TCP, shared memory or verbs, something like that for this other application to read and conduit kind of provides all of that. So right now it does things over MPI only with the MPI library. And then the other swizzle we have on this is it basically has an embedded, you can optionally have an embedded web server that allows you to get things to the web browser, which is kind of interesting. So via web sockets. But we haven't done any other transport layers for like IPC or anything like that. If we did, that would sort of be at a higher level functionality. It wouldn't be built into the core of conduit but it would be sort of a service built on top of it. Maybe using NANA message or some other sort of IPC thing or some other exotic network that would work well. Now as long as we're flashing back in time in the conversation there is a question that I forgot to ask too. Why JSON? Why not something else? How'd you end up there? So pick JSON because it sort of infected my brain a few years ago and it's been immensely useful for me for dealing with a lot of Python programming. I guess it's just very intuitive and I think YAML would have also been a good choice. I think XML becomes more complicated because there's so many ways to interpret it. So JSON, there's one way to interpret it and it works really well across multiple languages and I've seen that with my Python stuff and with how it's treated in C++. So that's why I picked it. I think and basically all the print things for human readability all shoot out JSON stuff. So I think I've convinced myself that it's fairly intuitive and I think I've convinced a lot of other people it is too but it may not be the absolute 100% perfect choice but it was a good one. Do you notice any performance issues in having to convert back and forth to JSON or is the JSON always metadata and so therefore relatively small typically in comparison to the actual data that's being passed around as a blob? Yeah, that's the kind of sweet spot for where we wanna use this, right? The metadata should be smaller and we're dealing with kind of bigger arrays and larger data sets. If we were to wanna target more kind of fine-grain things where the metadata approaches the size of the actual data we're passing around we probably would switch to some specific binary packed format or something which would probably look something like message pack or Bison or something like that but would just be, you know, would be a different kind of, a different schema description protocol.  So let's talk about the scalability of this a little bit. So we can describe partition data across processors so let's talk about the biggest simulation that you'd know of or can talk about that's used this as well as probably an example of a code that does lots and lots of descriptions like it has lots of different data formats and has lots and lots of descriptions because you did mention that there's a small performance overhead when dealing with this. Yeah, so we haven't characterized it very well yet. It's sort of, it's a dynamic sort of runtime API so a lot of the things that you're doing are going to sort of feel like what you would get from a scripting language, right? It's probably not as painful as all scripting language if it's sort of feel like that. We've used it to pass data so we've used it to pass data for an in situ context and I think we did it up to already 4,000 cores and the description of the data actually doesn't really, we're passing it actually zero copies so the description of the data really isn't very punishing on the performance at all. As far as what we're aiming to do, so one of the things we're aiming to do is back to this original sort of description of how processors talk to each other we're aiming to try that on like a 500,000 core simulation so and we will learn a lot when we do that, I'm sure we will but we haven't had the chance to dive into that yet but it's on the horizon so we'll see, we'll learn how well it works out. Now what kind of other applications do you kind of foresee on the horizon, right? You've talked a bunch about, HVC style of applications with well hierarchical structured data that can have small metadata conduits describing them and passing between libraries in the same process and things like that. What else do you see as being a useful scenario for this conduit type of passing? So we're trying to sort of, another thing we're playing with and we hope will be successful is sort of blowing open how to connect our simulation codes to the web and particularly sort of client side technology of the web because every supercomputer usually has a web browser on it and sometimes that's easier to build than X11 or it comes from the vendor, right? So there's a lot of great stuff you can do with a web browser now as far as analytics or visualization and we would like to have a good way of describing data between the two and getting data even if it's not big data, getting data between it. That's also another key reason why JSON was used because JSON will arrive at the web browser and sort of is at home there. So some of the things that we were doing with the new in situ capability actually is using conduit to talk over a web socket to a web browser and just send the image from a simulation back and it just makes things a lot easier if you can do this and you have sort of a natural context that also works on the web. So actually as we've been ramping up for this data science initiative at the university we've been having a lot more requests for people who wanna access data at our hospital and data at our U of M transportation research institute and stuff. And a lot of people are like, oh well just use web APIs but we've actually been finding difficulty and I'm curious if we can run to this too that a lot of these web APIs are not good for handling like if you want the entire history of the entire stock market it really doesn't work that well. It's still much better to kind of like offline dump that and move it around. And that's also manually intensive. So I'd be really curious what you come up with over the next couple of years. Yeah, so I think for the web stuff we're very much at the beginning here. We're trying to send smaller sets of data back and provide people context. But again, so if you can describe things with conduit whether you go to the web or whether you go to C++ it sort of looks the same way. So there's gonna be some usefulness there I think and how you can curate data with a solution like this. Let me ask you one question and I ask all developers who come on our program what version control system do you use for your software developments and why? So we're using Git for this. So we are publishing the code on GitHub. That's one reason for using Git because it's fairly common but we also have an internal sort of at Livermore we have an internal Git repository system and we use the Alasian tools for managing bug tickets and managing, for Wikis for data exchange or for ID exchange and stuff like that. So as far as Git versus Mercurial or something like that I think the more important thing is probably this distributed version controls. It's kind of freed up things to where it's easier to work on an airplane when you're flying across the country and push things and get things right. But so Git was a solution and I could talk about some of the more of the software engineering stuff that we also selected for conduit if you're interested. So if it's on GitHub I assume this is an open source what license is this under? It's a BSD style license. So then that's our preference so it could be used in commercial things as well without some of our commercial partners particularly on visit would be turned off by a copy left thing so we use BSD. So how does one Google for conduit? It's unfortunately a very common word and unfortunately has a name conflict with some kind of virus or something too. Yes, I noticed that like last week when I was dealing with my grandfather's computer that was quite unfortunate that I discovered that. So its presence on the web is really new. It's only arrived on GitHub and arrived with GitHub documentation and stuff over the last two months. So it's probably hard to Google for conduit itself. If you search for scalability LLNL you'll find a GitHub group that has a set of tools and conduit sort of lives under there right now. So scalability dash LLNL LLNL for Lawrence with a more national lab and that's where the conduit repo is and they're also linked to the doc current set of documentation is there as well. Okay, we'll put links to that stuff in the show notes too. So if assuming this is all open source and stuff how does one actually contribute and communicate with the group? So we have, so obviously through GitHub would be a good pause. So through GitHub would be obviously good opening up issue requests there and things. We track also things separately internally at Livermore right now just based on how things are working but you can email me, I will be the one to respond. So cyrush.lllnl.gov and that can give you more information on how we could attack things. Cyrush, thanks a lot for your time. All right, thank you. Thanks for having me.