Yeah, you have to turn it on. Great, so next speaker is Lead Nur and he's gonna talk about optimal enzyme profiles, principle and simple solutions. Okay, is it working? Yeah? Maybe I'll put it higher. Clicker, okay. There's no one? No, okay. Somebody talk to me. That one is for the... Who? That sounds really great. Okay, never mind. I'll manage. Okay, yeah. Thanks for staying so long and also thanks for the organizers for giving the questionable privilege of being last on the week. I hope I won't exhaust you completely after all the pizzas I had. I'm also a little bit digesting, but I hope it's not... I tried to make it light, so please also stop me in the middle. I mean, you already know that you can do that, but stop me in the middle if there are any questions. So, yeah, so the idea of this talk is to talk about optimality again, the cursed word, about the optimality of pathways, but I think I'm not... Just want to say in advance we're not taking optimalities too seriously in this talk, okay? We're just trying to see what happens when we assume optimality and I'll start with a quote of Terry, like everybody else does. Yeah, we should always tweak files before assuming it. The problem is I made this presentation before the quote was made, so I couldn't really change it in the last minute, but I still want to try to justify why we do this. So, first of all, when you do it and it works, it's very, very satisfying. So that's why we keep doing it, even though it almost never works. But, yeah, that's one reason. Another reason is that usually, optimality doesn't work across all experiments and all conditions and all species, whatever, but it might help us understand why if something's up with them and what's the constraint of the system or maybe it doesn't care, but that's another option. But it's still interesting to know that, basically. And this is a bit closer to my heart specifically, is that it could have synthetic biology applications. Okay, so it's not, we're not just thinking about understanding current biology, but also how can we engineer biology maybe in the future? So that's another reason to think about optimality. And so, yeah, so, I wanted to start with genome scale models. Actually, today's tutorial is about FBA, so maybe it's a bit premature. But in general, these kind of very large metabolic models, they assume everything is linear or they need it for the calculations relatively fast, which means that you have to assume something about the reaction rates and what's binding them. And the most typical assumption is that nothing is binding them, which is not very realistic. Sometimes they're just bounded by some upper bound. So this is usually used in FBA for flux bound sciences for uptake rates. They're just bounded, and that creates a little bit more reasonable result. But the more advanced models just give an upper bound that's depending on enzyme levels. So if you measure enzyme levels, you know more or less what's the upper bound. But they assume the maximal efficiency can be achieved. And the last generation, I guess, of these models, they try to make some effective upper bound. So it's not really the Kcat of the enzyme, but something more like a K apparent, we call it. But it still doesn't change really between conditions. And that's a little bit of a problem, because as you know probably, some of you, that the flux of a reaction is determined by the enzyme level, but also some kind of nonlinear function that depends on parameters and some kind of metabolite concentration. So a brief history of what these functions look like. So I like this because it kind of makes an order of what a lot of people just use the word because, went in for everything. And actually I think you almost should never use their names, maybe. So Henri is the first one who actually came up with a kind of phenomenological reaction, which already looks like this rate law that we know. Mika Esmenten just a bit simplified, but also justified it based on some kind of time separation model, basically, that the equilibrium of the binding is very fast. But actually the people who I usually like to cite are Briggs and Halden, and Halden later, basically came up with this reversible rate law, which we call reversible Mika Esmenten, but actually they never did this work. Okay. So we are going to use Halden's rate law. I just write it a little bit differently here. So I hope it's clear enough. The parameters of the rate law are the enzyme, which we use epsilon, a little bit non-standard notation. Sorry about that. K-cats are the forward and backward rates. The maximal rates, forward and backward. And then you have S, which is the substrate level, and KS, which is the Mika Esmenten constant of the substrate, and the same for P. Okay. So this is basically a rate law that depends both on substituted product, and it can go both ways also, depending on the equilibrium state. And Halden also found that there is a connection between all these parameters and the equilibrium constant of the reaction. So enzymes cannot really change that. So that's another constraint on the system. The four kinetic parameters are connected in a way that enzyme cannot change. And then about 10 years ago, we tried to reformulate this law. So the formula at the bottom is exactly the same as the one at the top. It's just using different parameters. It's the same exactly. We just did it to basically separate it to three terms, which we call efficiency terms. So the maximal efficiency is the Vmax, like always. The middle term is like something that tells us something about thermodynamics. Basically, there is stability of the reaction. And it only depends on the driving force, or the delta G. We'll go into more, if you come to my tutorial on Monday, I'll go into more details about this. But it's also written in this reference. Sorry, it's not here, the reference. Oh, no, yeah, it is. And the last term is just the saturation term, which you already should know. Maybe there's a slight difference here that you also have the product in the denominator. But that could be ignored if the binding is very inefficient. Okay. So that was the introduction. Now the goal, I was talking about automality, so the automality problem we're trying to solve, and Bob yesterday already mentioned it, is how to minimize the allocation of enzymes in a pathway. And a pathway can also be a wholesale. We'll talk about it in the end. So it's very easy to do it when everything is linear, but when things are very nonlinear, it starts to be a complicated problem. So now we have all the parameters of the system are the enzymes, the metabolites, and whatever, the steady state if it exists. So this rate law case, basically, to solve this, we said let's assume we have a pathway. Like it's a simple example where we know all the fluxes. Let's say you can say they're all the same. And we just basically say the demand for every enzyme in this pathway is the inverse of all the efficiency terms. So the inverse of the Kcat, the inverse of the efficiency of the thermodynamic term and the inverse of the saturation term. And this is how much enzyme we need per flux for every enzyme. So summing all these up give us the total demand or the total cost in some way. And I think also Bob mentioned this, we proved that this is convex. So it's solvable numerically, at least. And there's only one optimal solution. I'm not sure cells care about this, but us as scientists, it's very useful because we can find it at least pretty easily and then check if it actually works or not. And we did it and we found some correlations. It's not perfect. There are a lot of things that are not optimal, of course, according to what we know now. Okay. So just to show a little bit, example of how this works. So if we assume it, actually throughout the whole talk, I'm only talking about linear pathways with no branching and only series of steps. This is a very simple assumption, I know, but this is what we need for really doing some kind of deep analytics. So let's assume this kind of series of three reactions from X to Y. And there are three enzymes here. Okay, so three demands basically. And what I'm plotting in these three plots are the sum of the demands. So all the three demands as a function of, sorry, this is only the first demand, the second and the third. The second and the third. And the last one is the sum of all three. And the X and Y axes are just the metabolite levels. Okay, so we have two or three variables, A and B metabolite levels in steady state and three dependent variables, which are the enzyme levels. Okay, and then if you plot them, you see that each one of them is kind of a convex function and the sum is also a convex function. The gray areas are the infeasible regions. So you cannot even run the reaction in the right direction when you have let's say too much of B or too much of A depending on the reaction. Okay, so that's why we get like this kind of triangle where things are feasible and within this triangle, the function is convex. I think you saw something similar in Bob's talk also. Okay, any questions so far? It's not extremely necessary for the second part, but it's an introduction. Okay, so we did this already a few years ago, but like lately we said we thought to ourselves, can we actually do this solution analytically? Can we, instead of the saying it's convex, saying what actually is the optimum point? Okay, as a function of all the parameters. And in general, okay, I'll tell you in the second part. It's generally not, but there are cases where it is. And why do we want it to be analytical? First, it's nice to have an analytical solution because numerical solutions sometimes tend to give you, not precise, or have numerical problems, basically, where you're not really sure that it's the optimum. If you have a formula, you can sort of see the patterns, you know, just from the math. You sometimes see some kind of connections that you wouldn't see, or you could see with a numerical solution, but you have to look for them, right? You have to plot them in order to see them. And from the math, you can maybe just find it just by looking at the equation. What's more interesting for me is that we might find some design principles. So why things are geared in some way because there's a constraint, basically, based on the algebra. And the last part is like maybe there's a mechanism behind all this, which is probably the main point here. So the problem is, as I said, is that there is no analytical solution for the general problem. So what I showed you before, that's convex, with a held-in rate law and everything. It's not solvable as far as we know. But we do... I mean, I'll show you in a minute that we can do it for simple cases where everything is linear and there are no branching points. And one other constraint I didn't say so far is that we cannot use the full rate law. We have to simplify it somehow. And you'll see that in a minute. So the model we're looking at, as I said, is a linear pathway. The number of reactions here is three, but it could be any number. We put a constraint on the total amount of enzymes. So we're trying to allocate the enzyme in the most efficient way to give us a certain flux. And in one of the cases, we also have to have another constraint on the total amount of metabolites in the pathway. But that's a side note. I'll get to it later. Of course, we can also do the optimization if we say that the cost of the enzyme is not proportional to their weight, to their concentration, but not necessarily in the same weights. So we can do it with weighted apertures. I won't talk about this today. Okay, so the problem, as I said, is that even the linear pathway, you cannot solve this rate law. It's just too complicated, as far as I know. So we did three different approximations and solved it for each one of them. The first one I'll start from the right, actually, has already been done many decades ago. And basically, it's assuming that the saturation basically is very low. Like, there's no saturation, there's no linear regime of the rate law. It doesn't look like that in this equation, but I'll explain in a minute how it works. The second approximation is close to equilibrium approximation, basically, or something that you can also say happens when you're completely saturated. So only delta G can actually change the rate, because the substrate saturation is complete. And the third example, or the more interesting one today is the Mikas-Menten approximation, which is going back in time to the one where there's no thermodynamic stir. Basically, the reaction is completely irreversible. So we solved all three of them. So I'll start with a mass-action rate law. So first of all, why is it called mass-action? That's because a chemical reaction that works typically, like, the only thing that matters for the rate is the binding of, or unbinding of the substrates. And that basically means that everything is linear and then ends up never saturates. So if you have more substrate, the rate will continue to increase indefinitely. So the rate, going back to the original formulation of Haldane, so this means that you're below saturation for both substrate and product, which means that this denominator is one, and then you get only the numerator, which is this kind of mass-action description where you have the forward rate, which is something times s, and then the backward rate, which is something times p. So this, it's derived from Haldane, but we call it mass-action because it looks like that. And if we look at the chain and say the flux in this pathway is, like, it's a steady state, right? So all the fluxes are the same. I don't need to actually reach my hand. All right, so the enzyme level times this right will be equal to j, and then we invert it and we solve it. And basically this has been done already in 64 by Whaley, and then you can see that you get the optimal flux when you distribute basically enzyme in a certain way, and the optimal flux will be a function of the first substrate minus the last substrate times divided by k-equilibrium. So this is kind of the equilibrium, this equilibrium of the whole system, in a way, divided by a very annoying term, but it depends only on kinetic parameters. So there's nothing else there. It's a bit hard to even understand, but it's like a product of a lot of the kinetic parameters. So this is a very, very nice result. It's been used actually today, even it was mentioned in Matthias' talk. So the Costa paper that tried to use it to justify why you don't want to have long pathways and you want to split, and they actually use this result in some way. So it's been known for a while. Okay, so now to the second one. Sorry, so again, I'm not sure if it's clear. I'm not showing you the derivation, okay? It's a bit long to show here, but you can read the paper. The second option is to say, okay, we're still kind of constrained by the... So we're still reversible, we still have forward and backward flux, but we don't care about the kinetic term, right? So we're saying it's one. And the dynamic is the only thing that matters. Okay, so all the reactions are, let's say when you're very close to a equilibrium, this is a pretty realistic. And this is our solution, but it's a bit, again, a bit too long to show here, but we couldn't actually solve it completely. So we have a closed-form formula, but it's not solvable. It's not invertible, basically, the function, but we found a very good approximation that works for any parameter as we tried, and it's almost with no error. So I'm showing only the approximation. And what's nice about it is if you compare it to the individual rate law, it looks kind of similar, right? So the total enzyme times some expression that looks a little bit like the rate law itself, right? One minus e to the date, delta g, but this is the total amount of Gibbs free energy in the system. So from the beginning to the end, ignoring everything in the middle. So we only care about the total disequilibrium. Okay, so this is, again, the second result. The last rate law we're considering is the Micaela cement one, which is unique in the sense that it's not reversible. So, basically, all fluxes go only in one direction. Okay, there's no reverse flux. And therefore, you don't see the product in the rate law. Okay, only the substrate. To solve it, actually, first we had to realize that you cannot solve it with the assumptions we made so far, because, like, basically to maximize the flux, you just increase the substrate indefinitely. You won't lose anything, right? So you just more and more saturated, you always increase the flux. So if you try to solve it like this, you get infinite solutions for the substrates, for the metabolites. So you have to add some constraint on the total amount of metabolites. So we added, like, the sum of them. All s i's is s dot. And with this, actually, you can solve it using just, like, grand multipliers, basically, inverting this function, deriving it. It works. And you find that the total flux, the optimal total flux is, again, proportional to the total amount of enzyme times some kind of term which is, depending on K-cats, the Km over K-cats, and this s dot. If s dot is very, very large, you lose this term, and then you just get the sum of one over K-cats, which makes sense, basically, because you can always be saturated in all the steps, right? So then you don't care about the Km. Good. So these are the three solutions I'll discuss today. And, yeah, okay, so, actually, we wrote this first as a kind of a chapter for the question. Perfect. Yeah, perfect timing. Yeah. This is nice. And, of course, now I see that it probably depends on s dot, but in this optimal solution with s dot, how the substrate considerations internal substrate considerations are relative to K-i's. They can be larger, smaller. Well, I guess they can be anything. More interesting when we... You're asking, like, how do they change with, what, with K-i? Yeah, and how do they... Okay, I'll get back to it, but basically, the system is not stable because it's irreversible. So if you... If you want to, like, a J, which is bigger than one of the K-i's, then you won't find the solution. Right? Sorry. Bigger than the total enzyme times one of the K-i's. Like, you won't be able to find a fast enough enzyme. And also, it's not stable in the sense that any... Like, it's... You cannot, like, there's... If you don't find the steady state, then it won't reach a new steady state. Right? If you just allocate the enzyme wrongly, you won't reach a steady state. It will just collapse. But the S-i's, basically, are very easy to solve. If you know the enzyme allocations, right, there's only one solution for the S-i's. So they're kind of... And as you'll see... Okay, as you see, everything is kind of flat. Anyway, you'll see it. Okay, so we were already pretty happy just with the mathematical results without any implications in biology. But then we thought, okay, maybe we can connect it a little bit also to some kind of results we know, you know, from... We discussed all week these results, so I don't want to repeat them. And the basic, I think, one is something that we know well now is the monocurve. Basically, why does... We describe this increase in rate law based on the initial substrate concentration. And... Yeah, and we... Actually, the question we had is, which one of these assumptions would work best to fit this model? I mean, I think you can already guess, but you'll see in a moment. So we considered, again, a very basic cell model with three steps. So one representing a transporter, one representing all the metabolism, and one representing ribosomes. And for metabolites, so the glucose concentration or the sugar, the intermediate imported sugar, like, let's say, the phosphorylated version of it, the precursors, which you can imagine are the amino acids or the tRNA charge amino acid, and the biomass, which is the proteome, mostly. Okay. And of course, there is dilution only of the last only of the last step. The other phenomenon we wanted to describe is this linear allocation of enzyme. Here I'm actually showing other ribosomes, because we already saw them many times. But the allocation of the lack operon, right? So when you increase growth rate, the lack operon actually increases. So basically when you're limited, you need to, carbon limited, you need to express more of the transporter to get more carbon in. And now I'm just laying down the assumptions that I've said. So again, the model has three steps. Yeah, three steps and then growth. The parameter we're going to change, basically see how we respond to it with the sugar concentration. The total enzyme is constant. The growth rate is maximized and the rate laws, so we're going to use the same rate law for all three reactions. Either mass action, thermodynamic, or mucous menten. Something we didn't include and we would like to, but it's a bit hard to do at the moment is the dilution of the metabolites. So the enzymes, of course, are diluted. We have to regenerate them. They are not diluted in the model, which is not realistic, because at least amino acids dilution could have a strong effect. We're not sure. Okay, and the extra constraint only for the mucous menten case, I told you. So the solutions are already written before, but I'll just, I rewrote them in the notation of the model, so there are three reactions. There's K, yeah, so there's Km of the transporter, the Kcat of the transporter. Again, r is ribosome and m is metabolism. These are the equilibrium constants. So for the mass action case, these are the three gammas. So basically what's nice is that we know how much to allocate. So sorry, I didn't say this. The allocation is the square root of this gamma. In this case. So we know how much to allocate to transporter, to metabolism and to the ribosome if we want to be optimal. And it's the square root of this function. Okay, and this doesn't change. So what's not realistic in this model is that it doesn't change. You see, there's no effect of the sugar concentration on any of these. And that's actually why you get this kind of monochrome, which I don't think is very realistic, which is a linear increase with the sugar, right? So allocation doesn't change. You increase sugar, all the efficiencies increase linearly and everything increases linearly and that's what you get. Okay, any questions? Okay, the equilibrium line is, of course, you cannot grow when s0 equals sn over k equilibrium, right? There's no driving force. So that's where you hit 0. Okay. Yeah, so as I said, the allocation of enzyme is constant. Again, not the very good solution, I think. The second one we tried is the thermodynamic rate law. I showed you the approximate solution, which we'll just use as is because it's very good. I just changed the delta G to the explicit description of it just to have the parameter we want, the sugar concentration, so we can see it here. So this basically, this function looks like this. A bit more realistic. But again, I have to say that there's two things that are wrong. First of all, it's not what we call a Micaelos-Menten curve. So it doesn't have the k50 in the same way. So the curvature is not the same. It could still fit the data, we don't know. But the main problem is that there's an equilibrium point here again. So you're not hitting 0 when you lower the sugar. There's some kind of limiting sugar concentration, which is based on k50. And if you make it very, very far from equilibrium, you will just get a very different shape. So these two things are connected. The other sad thing about this model is that the allocation changes not linearly, but also not in a nice way. It's even hard to, there's no formula for them. But they're basically changing in a very unexpected way and it doesn't fit any data. And the Micaelos-Menten kinetics is required a bit more work because we have four metabolites, but we want the first one to not be included in this constraint because it's supposed to be an external metabolite now. The sugar concentration is not part of this metabolic constraint on metabolites. So if you do that, you get this expression which looks very nice because it's again already you can see that it's going to work for the monoker. And you get the analytical expression for the maximal rates. Again, this maximal rate depends only on kinetics parameters. And this constraint as well. And we already called it the mono coefficient, which is the same denominator with a different numerator. So this is how it looks. What's nice I'm not comparing it to data yet, so all these numbers are just completely arbitrary. But you can already see that very easily if you have a measurement for the monoker, you can kind of get an idea of how it relates to these kinetics parameters. Because it's an analytical formula, we can also if it works, it can predict maybe how things change if you change one of these parameters. Hopefully. Of course, I should have said it before, every point on this curve assumes that the cell optimizes everything at every sugar concentration from scratch. So it doesn't matter what happened last night. It will always optimize everything again at this point. Otherwise the growth rate will be lowered. I'm always thinking about it. So the last thing I probably want to show you is the enzyme. So in this case this is the solution. The enzyme allocations are also expressions more or less on the same parameters and it also looks very, very complicated. But what's really, really nice is that you can rewrite them as a function of mu. Which is already a complex function of all these other things. But when you do that you actually see that it's a linear function. So the transporter actually has a negative sign so it's the total minus a linear function of mu and the metabolites and ribosomes go up with mu. And this is what it looks like. Of course the numbers, again, don't look at the numbers. I just used all the parameters are one I think in this model. Something else to know about this. So the lines go, yeah the sugar concentration goes from zero to infinity as you go with growth rate. But the line stops at some point. They don't go all the way down because there's the maximum growth rate you can reach is here. So they just have to stop somewhere. Okay, so I'll just summarize. So we tried three options. I would say one of them works and the other two basically is very simple terms. And we tried to figure out why the caspenton case works. And I think we can generalize it a bit. So we don't have to assume everything is a caspenton. What really matters is that the transporter is a caspenton. So that this reaction basically is saturable and not reversible. Then you always will get something like this. So the allocation of enzymes will shift between the transporter and everything else. So the transporter will go down with mu and the rest will go up with mu. But inside the cell, things will stay always proportionally the same because if you solve it once, you solve it for every, all the time because there's, again, the transporter is irreversible. So there's no there's nothing changing inside the cell except the flux. So everything just scales up proportionally all the time. In terms of enzymes, not metabolites. So metabolites don't change at all, actually. So that's actually a reason to get, that's where we get this curve. It makes sense a lot in retrospect. And we also tried it with a general enzyme cost minimization when we made the transporter more reversible, it looks exactly the same. Like in all the range of the model. Okay, so I'll summarize the, I have five minutes. Oh, okay. I started early, I think. Okay, so the mass action assumption gives us a mass action, a growth law. The terminamic assumption gives us something that approximately looks like a thermodynamic growth law. And then the cementer assumption gives us a monochrome which is also a cement type growth law. So I think, just forget about cell models I think, just if you have a few reactions that have the same kind of kinetics, approximate kinetics you can lump them together to one as long as of course everything is optimized you can lump them to one. And maybe this is the kind of mechanism that could be used by cells. Especially the last one is nice because of this linearity. So you can lump them to one operon and just like scale up the operon together. And that will give you almost the optimal solution all the time. Okay, so that's basically all I have to say so I repeat the mantra that the enzyme customization is a convex problem. We have a few analytical solutions I showed you today that are a bit more informative than just saying it's convex I hope. And we applied them to coarse grain models we find that only one of the three approximation gives us more or less reasonable growth laws. Of course the reality is more complicated but I think it will necessarily have to have this at least part of it will have to look like this kind of irreversible because it cannot be linear all the way of course. But I do want to say one last note that I think that and that's something maybe interesting to look at for you Terry is that I think the thermodynamic growth law could be relevant for some organisms that are really like the methanogens that are very close to equilibrium people have shown that actually like you can give them a methane and they made hydrogen so they're definitely all everything is reversible. So maybe their growth laws look very different right there's no irreversible step. So it could look more like the other one. Yeah and that's all I have these are the list of references and if you want to read anything then this QR code is the link to the presentation. You can just get all the references. Yeah, thank you very much. Perfectly on time so we can ask some questions so we are. So the question is what is the definition of the concentration you assumed that the epsilon total is a constant right? Yeah. So it's the fraction which is a constant one right? But the whole thing can change. I know in your information everything is kind of copy numbers but here we only have all the parameters that you saw in concentration. They should say that from now on. Can I repeat my question now because I still did not quite get it because it's sort of not my brain is tired after full day of talks but in particular this S total if I want to think of I know that of course biology does not optimize we learn the mantra so very thank you but if S total is something then it's some sort of constraint on you know you cannot pack too much metabolites inside the cell and easier model you told that if you don't impose this constraint everything blows up and I understand why because there is no limit how high you can take each one so it's tragedy of the commons easier model operates far away from the tragedy of the commons because in biology it probably is not super you know, a similarity unless it's caused by pH is not a huge problem so how the internal considerations S compare to S total and how they compare to capital case? Yeah so I think there are two questions one is if we assume that some of all metabolites is this actually S total is it really close to a physical constraint and this I think it's hard to answer but but I think I mean in E coli it's probably a bit low but there are organisms where like it's many almost a molar I guess so I think the total of all the metabolites so I think it could be a constraint for sure and the other question is like how is it compared to the saturation of the enzymes and I think Jaffer Binowitz has a very nice paper comparing KNs to actual measurements and it's actually they know like the variation is huge but basically the average is more or less like the same place so most the average enzyme will have the substrate around the KN which means that they don't want they could almost double the rate if they this wasn't a constraint and what emerges from your optimal model with Mekaitis-Menton part? what's the optimum yeah what is the OPS I can't answer that because we didn't use any real parameters yet so we just I just use one for all the parameters so it will be just some monstrous expression which you cannot I mean isn't it like could you flash back the formula again for the Mekaitis-Menton yeah something like something like this something like this right if I just completely stupidly think that the capital K over lowercase K is the same for all then this the whatever you have in square will be just basically 4 times capital K divided by lowercase K and basically then you will have comparable to 3 over K in the left-hand side except that there will be K over S total so I'm just I'm trying to digest this in some simplest I think the important question is how much S tells you how much you need to care about the left side versus the right side if it's very very low then you will be very far from being saturated and you really need to care about these optimizing everything goes to the KM if the S total is very very high and you have no constraint basically you can just saturate everything like nothing matters we used to call the pathway specific activity it's just like summing all the specific activities and you get like solution for saturation conditions so the relevant parameter is capital K whatever it is that's a dimensionless parameter right? capital K has units of considerations and S total has units of considerations the ratio of these two things so just to answer your question so for E. coli with these curves that I showed we can actually determine each of these one over KK of this and that and this works very well but roughly just ignoring the last term so empirically we kind of know because we have no handle on KM right? we don't know what S total means okay what works is this mono matches up you can estimate the one over KK for each of these and so it works out very well if you ignore the last term which means last term is small and in the limit where KT is smallest one then of course we get a trivial result that mono is just a transporter mono constant but the thing is this is all effective so when you do the proteomics you see the C-Sector changing whatever that's an effective KK for all of the kind of value that's expressed of which only like a few percent is used to transport the carbon you're actually using so you cannot use the actual KK the entire lack of operon that I was trying to it's not just the transporter but the transporter is again it's lumping of all things from the external metabolites to where it joins the rest of the metabolites so it's a really weird thing because optimization works beautifully I mean we know this number except that when you look at the actual enzyme if it's optimizing you want to say use all of the transporter you want to give it to LATOS it is not doing that the framework it's using the optimization framework it's almost like you call I know it's the framework it's stealing it I agree that's still a very interesting any other question ok if not thanks a lot we now have the tutorial on FBA


Hello, my name is Azul and I would like to introduce a Collective's app. Jonas and me have been developing this app throughout the last half year. I will briefly talk about what a Collective is and what implications that has for our app, but for the most part of this talk I will be demoing the app. In order to make that easier, I'll be using the app for the slides as well, so everything you get to see or most of it will be inside the app. So what's a Collective? Collective is a form of organizing and people use this form of organizing to do tons of different things. For example, there's people doing gardening and agriculture and collectives and in fact I'm standing in a garden that's run by a Collective. But there's also tons of other forms of collectives. There's collectives running hackerspaces, makerspaces, all kinds of workshops like bike repair spaces. There's collectives in culture and in politics and there's collectives running bars and festivals and parties. So in a lot of fields in society you can find collectives. But what's special about a Collective? So one aspect that we wanted to consider when we started developing the app is that collectives try to decide together. They try to avoid hierarchies and try to build consensus amongst each other. They also share ownership and with sharing ownership they also share responsibility. If people don't water the plants they will die and they are all responsible for it or they share the responsibility in some way. One aspect that we also need to consider when writing an app for collectives is fluctuating membership. People join the Collective and then after some time they leave again. Maybe they move to another town. Not part of the Collective anymore. And we need to make sure that the app still works for the entire Collective. So we thought about these things and tried to build the app that it fits these needs. And the main goal of the app is to build Collective knowledge. To allow a Collective to accumulate knowledge over time and share that knowledge amongst its members. In order to achieve that in a good way we try to encourage participation. So we try to make the app as usable as possible because we want to make sure that everybody can contribute. In order to deal with flexible membership we will make sure that the data stays within the Collective even if some of its members leave. So what's in the app right now? We have collaborative editing. So we're basically using the next text app for that. We have a welcome page for new Collectives that introduces the app and how it works. But it can also be changed by the Collective and that's actually what we encourage people to do. Try to adjust the welcome page so it becomes a welcome page to that Collective rather than the app. You can view old versions of pages and you can revert to them. So if you feel like you made a mistake or you changed something and later on somebody complains you can revert back to the old version. We try to integrate as well as possible with existing next code apps. So we're using the text app for editing as I just said. So that doesn't just give us collaborative editing. So people will have the same user interface that they're already familiar with maybe from other next programs. We're using the Circles app to manage the membership. So each Collective has a matching circle and if you add members to the circle they will become members of the Collective. And all the data in the Collective like the different pages are stored as markdown files inside your files. So you can also use your files in order to change the content of the files or add some files, move them around. It will be integrated seamlessly with the Collective. So what we'll be doing next is we'll release a 1.0 version of the Collective app alongside next Cloud 20. And in the next six months we'll see how that goes. We're looking for feedback and obviously talking to Collective that we're working with and seeing how they feel about it and what kind of features they're missing. We'll also try to improve some things in the other apps that we're working with to make them work more nicely within the Collective app. And we'll add some small features to the app ourselves. But for the most part we'll be seeing how it goes. We hope to have some more things to announce next year but we can't promise anything that we'll see how that goes. I would like to thank you all a lot for your attention. I would also like to thank the next Cloud Community for being such a welcoming place and also for providing the foundation that we could build upon. Our work was funded by the Prototab Fund so I would like to thank the BMBF, the Bundesministerium für Bildung und Forschung and the DLR, the Deutsche Zentrum für Luft und Raumfahrt for the funding and also for supporting us during the work.


In the tidyverse, tall data is convenient for iteration. Wide data is often useful for display. You should know how to transform your data from wide to long, or wide to tall, and vice versa. Wrangling these transformations has made simpler when you know a tidy introductory amount about regular expressions, and I'll introduce some specialized functions to simplify the transformation of multivalued fields. The first two videos in this series demonstrated how to iterate over a vector and introduce the per-map function. Just brief introductions, we'll dive deeper into that as the series progresses. In the meantime, I want to show a few tips about data wrangling, and the tips here are about separating multivalued fields and making data wider and longer. First, the separate grows function. It's a specialized function that transforms data into tall data format. In R, iterating over tall data can be more convenient and efficient, more convenient, more efficient, easier than writing a for loop. Nothing wrong with writing a for loop, but if you don't have to, this works really well. In this example, the primary professions variable is a multivalued field where each value is separated by a comma, and while the separate rows function can guess at the field separator, in this case a comma, a best practice codes the set equals argument to identify the separator. When we separate the data, the goal is to make one row for each value of the multivalued field. This is going to make the data taller, for longer, and transform the table from a 1000 row data frame to almost 3000 rows. As we run this function, notice that Fred Astaire from the name variable, is listed as having three primary professions, soundtrack, actor, and miscellaneous. All three are values listed in one variable within the same observation or row. But this is really three observations, and I want to follow tidying data principles, which is one row for each observation. The end result will be transforming this one row into three separate rows. It's easily accomplished with a specialized function called separate rows. Once transformed, notice that the other variables have some redundant data. It's not a big concern. But now we have the data transformed into a shape that's easier to iterate. It's easier to make a bar plot with the ggplot2 bar plot function for visualizing the frequency of professions, and I'll show you that at the end of this video. An alternative to making data tall is making data wider for a multi-value field. We may choose to separate the single variable into one variable for each value in the field. To do that, we can use the mutate function, but a specialized function is the separate function. It works similarly to the separate rows function, and then you can use an argument to identify the separator in this case a comma. By virtue of making the data wider, we mutate the tibble into more variables. This is done by identifying the new variable names using the into equals argument, which takes a character vector for its value. Let's see this in action. Notice in this argument, I'm using the str underscore count function part of the Stringer package, which enables me to leverage regular expressions or regex for finding patterns and data. I'll demonstrate more about regex in the regex lesson, but for now the important bits are that regex is composable code used to identify patterns and text. These patterns, they can get very abstract, but the simple patterns are easy to learn and they're very powerful. The simple pattern seen in line 127 is where I use the pattern of a literal comma. I'm using the str underscore count function to count how many patterns there are in a multi-value field. For example, in the known for titles field, a multi-value field contains up to four IMDB IDs representing the most widely known titles related to the primary name observation, that is a row. I can count the total number of commas and add one, and this gives me the number of values, that is the number of IMDB IDs in the multi-value field. Then I'll assign this number to a variable called prolificacy. Using the same regex pattern as my argument, I invoke the separate function, different from the separate rows function, to make the tipple wider and making the tipple wider splits the multi-value field into multiple columns. In this example, I transform known for titles into four discrete variables or columns. The code chunk that begins at line 121 demonstrates three different ways to use the simple regex pattern in a data transformation. I use specialized functions to transform data from wide to tall and then tall to wide. Of course, with a bit more code, I could do the same thing with the pivot wider and pivot longer functions, functions that I demonstrate in an earlier ARPUN video, an earlier ARPUN workshop, and I'll try and link that in the description. I tend to use the pivot wider and pivot longer functions more often, but these functions separate and separate rows are so handy that they're good to know about. But now for the cool part. Since I know how to transform my tipple with a multi-value field that is primary profession, I can use separate rows to pivot the variable longer. Then, it's easier to iterate over tall data with the geon bar function in ggplot2. For more advanced examples, stay tuned for later videos as I combine regex pivoting along with other custom functions.


from Korea to Germany, from Alaska to Puerto Rico. All over the world, the United States Army is on the alert to defend our country, you, the American people, against aggression. This is the big picture, an official television report to the nation from the United States Army. Now to show you part of the big picture, here is Sergeant James Mansfield. Today, we look at the American Army in Germany, the United States 7th Army. This area, along with the section of Berlin, is the sector we hold out. To the west is the French sector, the British in the north, and in the east, the Russians. We've maintained troops in Germany ever since we cracked the Siegfried Line, and at first helping to denazify the country and helping law and order back on its feet so that one day, Germany might regain its place in the family of nations. When the Cold War in the Far East reached the boiling point with the outbreak of hostilities in Korea, the Cold War in Europe lost none of its chill, and still today, the 7th Army is ready for anything. And now, the big picture inspects the Army's effort towards getting ready and staying ready in Europe. In Berlin, Germany, there's a big bell. It hangs high in a tower of the Schoneberg Rathaus, seat of the government of West Berlin, a gift of the American people to the people of Berlin. Maybe you were one of the thousands who chipped in for it. On it, there is an inscription that this world under God shall have a new birth of freedom. At precisely noon each day, this bell is rung. To keep that bell ringing to help make the bell's message stick, that's what the American Army is doing in Germany, alongside our lives of the North Atlantic Treaty Organization. That's the job of the United States 7th Army. In the hottest spot in Europe today, it spells out just one word. Alert. For occupying Easter in Germany is a power that has long declared its intention to dominate the world. Army go home, they say.  And behind their curtain, they mask their strength. We don't know when they're going to move or if they're going to move west. But whenever and if ever, we've got to be ready.  The big guns are ready with live ammunition, and so are the small weapons. The machines are ready and so are the men. Alert. A word here that means two things in the big picture. Ready to discourage an enemy from striking? Ready to meet him if he comes. But you can't keep an army wound up like an alarm clock just waiting. So the 7th Army comes and closes at Cannes to fighting its own war in Germany. In maneuvers like the recent joint United States-French exercise Rosebush. With the arrival in the field of Lieutenant General Charles L. Bolty, then commanding general of the 7th Army, and now in command of all United States forces in Europe, the exercise is launched. At all 600 hours, an aggressor force of 25,000 American and French troops, representing the armored spearhead of an enemy, went into action in the cold rainy dawn of northern Hesse. Mission? With a lightning surprise attack to seize the vital river crossings of the Middle Rhine between the German cities of Mainz and Bonn. With the job of defending the territory, 50,000 friendly troops, specific mission to cushion the shock for 72 hours, while a strong defense line could be built up along the Rhine. And machines on the move. The aggressor elements trying to plunge through in four armored columns. The defenders slowly withdrawing, trying to keep their units intact, but delay the aggressor for those long, long three days. All the knowledge, all the training and conditioning of every man put to the test that might one day come for real, with bullets instead of blanks. No enemy fire overhead, but if there were, the troops couldn't have moved any flatter. No enemy machine gun cutting loose on the embankment, but a sortie against one couldn't have been executed with much more realism. And when a man hit for cover, he hit, even though it might be a little soupy. Nothing to hide from, except maybe the future. But the time to learn to smoke screen a movement is now. Where a mistake can be pointed out by an instructor instead of an enemy marksman. And it's food on the fly. And the stars and stripes, the GI newspaper, really on the fly, delivered to troops in the field by helicopter. And in place of enemy fire to determine which troops would have been killed or captured, umpires like the Major. Even though it sometimes took an argument to convince an earnest lieutenant that he and his men had been legitimately captured by a French unit. But as in any kind of game, even one of war, the umpire is always right. French Marshal Jouin, NATO commander of Allied land forces in Central Europe, was one of the many high-ranking officers on hand to study the preparedness of the troops, along with high-ranking officers from almost every nation allied to us by the North Atlantic Treaty, like Portugal's General Pinto Ribeiro. The German population, too, got an eyeful of the strength that is ready to be muskered should trouble burst out of the east. And just as wherever the United States Army goes, the smaller citizenry got a stomachful of chocolate bars and gumdrops. But out in the country, there were some hopping-mad farmers until they learned the army would repay them for crops unavoidably damaged by the great treads of the tanks. For three days and three nights, exercise rosebush went on. Towns fell and were retaken again and again.  The defenders held stubbornly to every foot, every vantage point, till superior aggressor power incontrovertibly put them out of action. At the end of the exercise, the critique, our own high brass with that of the NATO nations conferring with the officers actually commanding troops in the field to push it out, to find out what was right and what was wrong. What is the potential of the forces committed to dissuading or stopping an enemy attack? Opinion, certain kinks to be straightened out. Concepts revamped. But verdict, our forces are on their toes, ready with just about everything they have towards discouraging or halting aggression. But to get back to that word, alert, the key word of the 7th Army and what it means to the American soldier, the GI himself in Germany. Sergeant Martin here is pretty typical. How about it, Sergeant? Alert, what is its significance to you? Well, right now I guess it means getting this VHF antenna up. Communications. It'll bring into the command post here the high frequency signals transmitted from battalion headquarters. That's the job for today. But you know, alert means something else to us GI's stationed here in Germany. We live a pretty good life when we're not in the field. Almost like back home in Detroit, except for that word, alert. Take me for instance. I've got my car. I've got a pretty good home here in Frankfurt. Nothing fancy, but I've got my wife here and my kids. Karen, she's in kindergarten. Special school for Army youngsters with teachers right from the States. Yep, and Christopher Martin. Born in Frankfurt, Germany. I never thought that when we were coming through the Siegfried Line. Leslie, Mrs. Martin, she's been over here for quite a while now. It was a little hard at first, maybe, for her to adjust. And now you'd think she was brought up in Germany. Bet she sets as good a table as any Hausfrau in Frankfurt. Knows how to shop. Of course, there's a commissary for military personnel. But there's shopping to be done with the German merchants, too. Good morning. Good morning. What's the cost of this? I don't know. Okay. I don't know. Anyway, it all adds up to good chow. For the rest of it, it's pretty much like it would be anywhere else, I suppose, for a working man. Of course, the football game you watch over here is soccer.  With a built-in alarm, they can go off at any moment to ring that alert. There's church on Sundays.  There's window shopping with the wife. Western Germany's really back on its feet, too. Plenty to shop for. Yeah, even a hot dog. Except that in Frankfurt, we call them Frankfurters. Then sack time till 6.30, when the kids blow their own special tune for Reveley. That is, unless... Yeah, yeah, this Martin. Okay. Okay, I'll be there. After the happy family life of yours truly takes on a different picture. The whole family is geared for getting pop-out on the fly. Because there's just one thing we're really here for. And whether it's the real thing or another practice alert, we've got to be on our toes. A good part of most GI's time in Europe is put into special training to better fit him to meet an enemy wherever and however he comes. At the Mountain Warfare School, Salfeld in Austria, it's done on skis. A little clumsy now, maybe, some of them. But before the course is over, learning from Austria's top instructors, men who never saw a pair of skis before will be riding them as though they were born wearing a pair. Sport? Sure. But with obstacles that don't usually grace the polite ski run, they'll stay at it till every man can make that ditch and keep going. And they learn how to survive in the snow, too. To live out in it and build their own shelters. Be it ever so humble. Soldiers on skis, mountain troops, ready to go places on the white stuff fast, if that's what's called for when an enemy strikes. In Lund, Greece, Germany, a former Nazi SS installation is used now by us for training infantry scout dogs. A nose for trouble, recruited and trained to sniff it out on patrol. Most of the commands taught in infantry dog are silent. You can't yell out here, Fido, when you're prowling around enemy territory. And the dog has to learn something about that old business of the army traveling on its stomach. He must develop unquestioning obedience, regardless of what he is asked to travel through. Or, for that matter, over. He also has to learn to be tough if necessary. The idea isn't to make him a one-man dog, exactly, but he's got to know that there are people in the world who are supposed to be fond of, and that it's okay for him to attack where his nose is smelled out trouble. And every soldier has to learn to drill to proudly swing out with soldier master in an infantry scout team. And here at Degrendorf, Germany, is where army nurses learn to be rugged. In an intensive course, every nurse learns how to live and work in the field, even to putting up their own canvas hospital. Learning to work outside the big, well-appointed hospital without the helpers and the stainless-steel operating table. To understand what it's like to perform, where a soldier's life can depend on the speed and the know-how of the nurse up front. With the start of the shooting in Korea, every effort's been made to conserve supplies and training, as here in the Artillery Observation Course in Munich. In this problem, you will focus all the knowledge of artillery that you have gained in your other classes upon the destruction of a specific target. Gentlemen, your field of fire will be this puff port, which represents the actual terrain with road intersections and the church steeple. The maps that you were issued prior to the class represent the area that you see before you on the puff port. Okay, Sergeant of Spain, you take the first problem. Your target will be this tank in the wooded area here. Now, Sergeant, fire this mission just as though you were on the observation post in the field. The ingenious puff port lets the student perform as though he's calling for actual artillery fire. Chemicals simulating shell bursts register his shots on targets. Forward observer, Abel Cummings. Fire mission, Asmuth 5800, marked center of sector. Enemy tank will adjust, 400. An operator under the puff port simulates fire on the exact spot it's called for. Over line, drop 200. Okay, Sergeant of Spain, you're on the target. Now, what will your next command be? Repeat range and fire for effect. It isn't all training for the GIs in Germany, though. Through the German Youth Activities Organization, they're doing some of the teaching themselves, teaching German kids a way of life for one thing. The GYA just sort of grew up from the days when American troops were taking swastika-handled daggers away from Hitler Youths and teaching them how to play baseball instead. Now in almost every city and town in the American sector of Germany, GYA clubs sponsored by the Army bring hobby and art instruction, recreation and sports to thousands of German youngsters. And boxing gloves with Marcus of Queensbury rules in place of Nazi daggers. Then there's the soapbox derby each year, held by the GYA. Each driver has his own GI sponsor and coach. Enterance come from all over the American sector to the final heats on a Frankfurt slope. American general to the winner. Symbol of the thought that the soldiers of a democracy are here to help, not as conquerors. Seventh Army troops have had other opportunities to demonstrate themselves as good neighbors in Europe. When Holland's dykes went out under the hammering of tremendous seas last winter and new storms were blowing up, Army engineers went into fast action. Sandbags were the fingers in the dykes this time and GIs prepared them by the thousands working night and day to ready the dykes against a new onslaught of nature. A bulwark against the further devastation of flood. The Dutch will not soon forget what help rendered in time of desperate need by American soldiers working shoulder to shoulder with their own men around the clock helping to save the lowlands from further ruin. But mostly with the Seventh Army, it's preparation to meet man's worst catastrophe, war. Remember all the river crossings our troops made in Germany when we were shoving ahead in World War II? Well, our army is still crossing German rivers the hard way in training exercises like operation boat ride. Problem. A division crossing of a mine river from Hanau to a Schaffenberg. The farther shores theoretically held in strength by the enemy. To cover the crossing, keep the enemy ducking on the other side. Heavy firepower, division artillery including the big self-propelled howitzers are ready to throw across a curtain of steel and lead as a screen for the hazardous operation. Machine guns ready. The artillery man working is fast against time as though lives depended on the quick ranging of the pieces. The combat engineers, too, fighting the clock as they hurry the construction of a bridge across the river. A bridge on floats that must sustain the thousands of tons of a division's armor. And meanwhile, the infantry moves out to secure the other end for the bridge, a beach ad on the enemy shores. A striking force that has to hit hard and fast is a dangerously exposed job of a river crossing. Tanks, too, ferry across the mine on steel treadway rafts to join in the simulated fight for the beach ad. Armored support for the infantry to smash ahead where enemy resistance is most stubborn. And let them roll. We did it before and to make sure we can do it again if we have to. We're doing it right now in the strange shadow war we wage in Germany. Your seventh army on the alert is in trouble out of the east. That this world under God shall have a new birth of freedom. That's your seventh army in Germany. An army devoted to discouraging a fight, but meanwhile, building up a solid, stiff punch should it come. Next week on The Big Picture, it's firepower, the story of the artillery. A study of our great new atomic cannon. A look at the fantastic sky sweeper to keep enemy aircraft out of our skies. Also, The Big Picture will show you how American artillery is employed in Korea. How and why we fire 10 shells for every one the Communist fire at us. You're invited to be with us then. The Big Picture is a weekly television report to the nation on the activities of the army at home and overseas. Produced by the Signal Corps Pictorial Center. Presented by the U.S. Army in cooperation with this station. You can be an important part of The Big Picture. You can proudly serve with the best equipped, the best trained, the best fighting team in the world today. The United States Army.


Eric, is it going to talk about OGRT how you can keep an eye on what your users are doing on your cluster? Exactly, so I'm going to give more of the system administration side. So, I'm Garag Rath, I'm a systems engineer currently doing freelancing. So, I'm the guy installing CentOS 5 on your machine and ruining your modules. So, I want to start at the beginning like what is a job from the administrative side. A user gives a script to your scheduler, whatever is inside the script gets executed, you get basically start time and time resource usage. So, for me, that was not enough. So, what else is happening? You have programs executions, the programs loadshared libraries, depending on the environment variables that are set and depending on the loaded modules, which is basically the same as the environment. So, the question is why would you want to know what's going on inside your job because you're basically just an infrastructure provider or not? One of the questions is what software do my users run? Because you just heard it, it's like a wild west out there, everybody's installing their own software, so I would like to have a way to figure out what the users are doing. Why? Because maybe your users are using, I don't know, an unoptimized Python version from their home directory that they got from a colleague or a binary build of a software that you would have optimized, maybe infinite support on your machine. Maybe some blast library had a bug that happens, so maybe rounding was problematic and you need to inform your users that there was a problem and optimally you would like to supply them which of their jobs had a problem and what they need to do to fix those. And from more of an administrative standpoint it's interesting if you build software for your users, can you reduce the profile? So, if you have software that does not get used, you can basically throw it away and don't rebuild it when you build a new machine. And to help the users basically figure out if their environment is the same. So, if you run a program and library path is set wrong or you build a program and the environment is not the same then your user is going to run into problems. So, how would you do this? How would you approach this problem? And we tried several steps, like the first thing is you ask your users. That's simple to do. You go to the user, ask okay, what do you do in the cluster? How can we help you? And then you won't like the answer because it's usually, we use this pipeline and they got it from somebody and you could check everything that's going on there which is very hard. Repeat this for every user which obviously does not scale.  Alright, so I'm going to explain this briefly. If you do, a module system is a way to load and unload software in different versions. So, module load, in this case, emboss for example, loads emboss in the most current version. If you would do an unload, it would unload it. It does that by setting environment variables. So, what users like to do is in your profile, you load all the software that you use often. So now you have a problem that a module load, if you track that, it's not actually the software that the users use, it's just what gets loaded and if that's in your profile, well, that's not exact. So what does OJT do? It tracks every program execution in a job. It tracks which shared objects a program loaded. So you get a very exact representation of what happened at the time the program was run. It embeds a signature into programs and shared objects which happens at compile time and the little starter, that's completely optional. So you don't need to embed signatures in your programs if you don't want to. And it outputs the data currently into Elastic Searcher Splunk, but it's pretty open so you could use any backend you'd like. I just recommend something where you can do analytics in. So, what's unique about this, this works without a launcher. So you don't need a wrapper around the programs. You don't need to do anything, you just set environment variability track, everything that's happening inside of a job. It's very lightweight. Everything, like reading the signatures, it happens in memory so it doesn't hit the disk, so it's very fast, it's transparent, which in this case means if anything fails executing that, like because it gets executed with every program execution, nothing happens, your user will never see and the programs keep on running. It's resistant to outside influence, which means the environment has no impact on the functioning of OGT, so it has no runtime dependencies. There is very little that can happen to influence it and that's more for the system administrator, so it's very easy to deploy. So how does it work? Which is the interesting question. In depth here. For executing OGT with every program that gets loaded, the loader has an environment variable that's called LD preload, which forces your program to load a shared object. GCC and GLIP-C has a constructor which gets called every time you load a shared object, so that basically makes it that OGT runs inside the address space of every program that you execute, so you get every execution, not only the stuff that you build as a system administrator, that gets loaded as a module, but also the stuff that your users build in their home directory so you get everything except, there's a tiny exception there, programs that don't use the loader, which could be statically linked programs. There are ways around that, so you could compile it in, but I currently don't do that. So we talked a bit about this watermarking, what it does exactly is you have an ELF file that gets executed and it embeds a UID into a section of the ELF that is done by GCC as well and by the binutils. And what's interesting about this, if you embed this section into the ELF, it gets loaded on execution, so it's in memory, you don't need to go to disk. Also an interesting question is, why would you have such a signature? It's the same path, can have a different executable, your user could copy for whatever reason a program to its home directory, stuff like this, so you can identify the software exactly, not only by path because that's not the unique identifier, you can discern user-generated programs, so if a user recompiles a program, if you're wrapping the linker, you get the recompile and it's just a unique identifier. So that would be an example of a signature, you can do it with Redelf, so the first output here is OTRT, which for Redelf is an unknown type and then you have the ABI compatibility and the build ID that's done by GCC, so that's a mechanism that's pretty well known and it works very well. And down here, if you use OTRT to look into the signature in this case R, you see that you have a unique ID, allocatable means it gets loaded into memory when it's run and the version number. So the functioning of OTRT is like this. The black box on the outside would be the address space of a program in this case because we're in a big data there from its R. LibOTRT.so gets loaded into this executable and it executes the code which goes to all of the stuff that the linker loaded and checks if it finds a signature of OTRT. If it doesn't find when it's okay, it just notes the path. The rest of the stuff, it wraps this up into a package and including other stuff. For example, it does the environment. OTRT is very configurable, so at compile time, your C7 decides what he wants to monitor. You can send certain environment variables where you know that there are problems. You can do all environment variables. You can send the loaded modules. You can decide to blacklist some stuff, for example, user bin because you don't want to track LS. So that can be done. And now it's the question that's a lot of data. How do you persist that? How do you make sure that gets somewhere where you can use it? So there is a transport which is the server. So you have liberty.so which runs into your program. It packages up all the data, like environment, shared objects, et cetera, et cetera. In the UDP packet, that sends it to the server. And the server then sends it to configurable outputs. At the moment, the data stores implemented are Elastic Surgeons blank. File is also there, but that's for debugging only. Don't use this in production. The server itself is written in Go. It just takes the UDP packet, opens it up, decodes it. Internally, it's a protobuf. So if you would like to write your own OJT, it would be compatible. It decodes the data and forwards it to the outputs. Because of the nature of the runtime of programs, because you could execute, I don't know, if you have 10 compiles running at the same time, that's a whole lot of volume of data, the server buffers the data. So it takes the data, puts it into a buffer, and then if the backend is too slow, it just smooths over these specs. It is a tiny embedded web server, which displays metrics. So in this case, at the moment, there's only one input. So you see how many packets it processed, what was the rate per second of the packets, how long did it take. The reason to notice that the input, because it only copies data to a buffer, is very quick, very fast. And here you have an elastic search output configured in the bottom, and you see the stats there. So in this case, the input has 270,000 packets, so the backend is a bit slow, which in this case, it ran on my laptop, so that might be a reason. I implemented very, very basic lookup functions into this web interface. So what you see here, there is a blast library. There is a blast library that was broken. I say, I know the signature of the library because I built it. Then I press lookup and it displays me the effect jobs. So if I use these jobs with my accounting database, I can inform the users of certain that this library was broken and they should do some steps to fix that. Having said that, because this uses an elastic search back and I recommend using elastic search or any other analytics platform of your choice, because in the case of elastic search, you get access to a whole ecosystem. You can use Kibana to do interactive analysis of the data. An interesting use case is if you have your resource utilization of the job in Grafana dashboard, you can say, give me the data from elastic search and overlay it so you would see the usage, let's say memory usage of the job and overlay it with the program executions. So I don't know, you start the memory hog and then you see the disk cost, the memory usage to go higher. Plus, stability and performance is quite good using elastic search. That's a slide more for the administrators here. It's very easy to deploy because the server is go. So it's a static binary, you drop it somewhere, look into the configuration if you want to. That's it. The client is basically configure make and there is a vendor as script. So if you want to try this out, it downloads the dependencies automatically, compiles them with the flags that are necessary for that. You type make install, then down here, you preload LibOchert, set it to active. If you don't set it to active, it doesn't do anything and you need to turn it silent so there is no accidentally running in the background and if you open this Bash here, everything you do in there gets sent to the server and processed. So in conclusion, Ochert is a more of a sensor that gives you deep insight about what's running on a machine, like on a cluster inside a job. It's a versatile tool. It's very configurable to your needs so if this is too much data and you want to blacklist something or filter something that's very possible, it's very easy to deploy. I mean, I might be biased. It doesn't take more than 10 minutes and it's what you can do with it, with the data that it gathers. You have a sense of the software that your users use which includes what they build themselves. You can troubleshoot problems so if you see that a job failed, you, without talking to the user, not that you don't want to talk to the user but it saves the roundtrip, you can check preemptively if there is anything obviously wrong and right in the middle of something. You can retroactively inform him about buggy libraries and reproducibility seems to be a big thing so if you know how a program was run, including all the environment it was running, I would say that contributes to reproducibility. What I want to do in the future for our duties, some of the queries that are interesting building into the web interface, like very tiny stuff, then maybe take another transport and usually infrastructures like this have syslog so it would be interesting to instead of the server put it into syslog if you want to. Question about the format. There is another thing which would be very interesting. There is a kernel facility called eBPF where you could basically do the same that OTT does in kernel which would make it faster. It would be an interesting evaluation there and what you can do with the linker, track not only which shared objects your program loaded but also if it uses them because the linker provides some hooks that make this stuff possible. So with that, I'm going to go to questions if there are any. Thank you. Would this clash with anything else? Well, you would need to attach it. The question was would this clash with anything else that uses LD preload? As far as I'm aware you can preload multiple things. Now, as far as I'm aware and it has been running in production it does not clash with anything. It does not modify the binary in any way so it's very self-contained. So the question was is there an alternative method instead of using LD preload? Yes, you could compile it into the program itself as an object file. I used LD preload because it's very easy to do. You could also, in our GOT but I did not want to do that. You could enforce that preload is always set to a value that you want it to be set to because basically if you're inside the program you can overload and hook and make sure that it gets loaded. So you could do it like this. You usually do it in a module file where you do module load or GOT. It sets LD preload and then from that you're set. Graduates just walk in and in and then papers submit and suddenly the environment changes. Could you use this software just to track when something hasn't been used for a long time a version of the software? Sure. We're going to delete this. Don't delete it. Well, you haven't used it for six months. Okay, I'm going to repeat the question. The question was can you use this to track if software hasn't been used? And the answer is yes. You can very well do that. Well, the question was what did you find out? What did users do wrong? I would say it's more of a reactive thing. So if you know that there is a problem you start using this data to... I mean it would be interesting if you could use this data with some kind of method to automatically decide if something is going wrong but it would involve some machine learning probably. I don't know. It's not my experience. Is there something with AWK? Oh yes, machine learning or AWK. No, I mean AWK was being used a lot. Ah yes, you get... We found out that the most valuable bioinformatics tool is AWK apparently. It gets used a lot. And then if you know this for example if you know AWK gets used a lot which may sound stupid but then you can say okay there are optimized versions of AWK so we're using an optimized version of that you could bring your users to speed up, for example. I have one more question. How much of a big data problem are you creating here? How much data is being pulled in for every process or every job that gets run? Like in volume it's quite small. It would be a kilobyte like a packet that the program sends is one and a half kilobytes including everything. When it's addressed in the elastic search I don't know how much it takes but I mean of course it's big data, it's gigabytes. Alright, thank you very much Georg.