of work on electrochemistry, on oxidations, and all this. Also on ab initio thermodynamics and multi-scale modeling related to the topics of this conference. And today, she will talk about the insights into processes and solid liquid interfaces from ab initio molecular dynamics. So Mira, the floor is yours. Thank you very much for the nice introduction. And thank you very much to all the organizers for inviting me and giving me the opportunity to present our work at this very interesting conference, which I enjoy tremendously so far. So I hope that I can add a little bit to it by showing us our work on solid liquid interfaces. And I don't have to convince you that solid liquid interface is ambiguous and are at the heart of many processes we are interested in. We've heard examples of various problems where solid liquid interface is playable. This is only a small part of them. And what we want to understand when we want to understand these processes, we need to think also about multi-scale modeling. We heard about this. We need also to think that when a certain device is produced at the laboratory scale, we need to think about upscaling. But these are problems I'm not so concerned with. I'm more interested in the fundamentals of the underlying processes. And now, while we see something like a erosion on the macroscopic scale, of course, where it starts is a diatomic scale. And diatomic scales, this is here. A cartoon view is not simple. And we've heard through all these conferences a lot of different talks about approaches and techniques, which help us to learn something about this atomic scale and the processes that are going on there. What you can see already from this cartoon picture is that, of course, we have to be concerned with very many different materials classes. Obviously, there is water, which in terms of modeling will put very different, will present different challenges as compared to the modeling of an oxide or a metal. We have to think in particularly about statistics when we think about water. And we can either try to use molecular dynamic simulations or we can try to describe water in some kind of average way or continuum modeling, as we also heard about, for example, by using some vast solos mentioned several times throughout this conference. When we think about, of course, oxides and metals or solids, usually we kind of do from the theoretical modeling with more idealized systems and don't care so much about the defects that may be line defects or even grain boundaries and dislocation and so on. But even if we look kind of at perfect systems, they are very challenging to model in conjunction with water. In the end, what it boils down to at the microscopic level is the making and breaking of bonds and chemical reactions, which we want to understand. And as a consequence of this, of course, we get old structural rearrangements that happen at the interface. I'm using density functional theory modeling, or at least I base all my modeling on density functional theory, which provides us information about the geometric structure, the electronic structure, and also about the energetics. And what we want to learn is how the environment, which is determined by its pH, electro-potential temperature, would influence this solid-liquid interface and the processes that are coded. Now, the sixth I would like to touch upon is how do we really study such a solid-liquid interface and understand under potential control and understand how the interplay between the solid-liquid interface and the potential kind of influences what is going on there. But I will first talk about how we can realize the potential control in a periodic density functional theory code before turning towards three examples. One is concerned with the platinum water interface and has been already touched upon in at least two previous talks, the one with the absolute bulls and the one with June Chen. And I would like to talk about the impact of water consumption on the electro-potential. The second example is from the area of corrosion. And there I would like to discuss how our use of really potential control allows us to understand the magnetic corrosion and the anodic conditions, in particular also the evolution of hydrogen that occurs there, which is a problem that hadn't been understood for a long time. With this, since I will be talking about metal water interfaces, I thought I'll show this picture about the solid-liquid interface, which you've seen already. The double layer structure has been discussed. And even when we look at the microscopic scale, of course, it is a complicated interface, even if we don't consider all the complication coming from oxide formation and so on. Because we have two condensed phases, which come into contact, which have different surface type, there will be a potential drop. And of course, when we go towards the bulk of the water, then this potential drop will eventually flatten out. And this region of the double layer is something which would determine in the end the properties of the interface. Because we are dealing with the metal, all of this potential drop is on the water side. If we are dealing with a semiconductor, this picture is a little bit more complicated because then there may be also a certain space nitrogen in the semiconductor. Well, if you want to model something like this in a DFT cell, we want to have an electrode. We would like to have some kind of reference counter electrode. And of course, we would like to have an electrolyte. If we don't have any potential control due to the potential drop at the interface, there will be a dipolar layer of water at the interface. And this will be the potential difference that we measure between the fermi energy and the metal and the other side of the reference electrode. Let's say this will be the potential of the charge. This was also already discussed in several presentations. If you apply a bias or the electrode is charged in some way, then of course, there will be rearrangement of the interface to screen the additional charge. So there may be specific absorption. Some ions may be pushed away further from the interface and the potential will increase. However, apparently, if the cell species are able to counteract the charge on the electrode, most of the potential drop is seen. Eventually, this won't be the case. So also the ions which are in the solution will start to kind of play a role in screening the potential because the dipole that is built up here will contribute to the screening and the potential loss. At some point, there may be various may be overcome and then the potential change will drive electrochemical reactions. And this is something which, of course, we would also like to be able to influence from then either increase reaction rate or maybe suppress a reaction. In terms of smothering, what we would like eventually to have is a cell in which, as I said, we have a reference electrode and this reference electrode is able to basically account for all the excess charge of the non-neutral diffusive layer, but also to be able to allow us to charge the electrode. And how do we do something like this? So what are the design elements? You want an electrified electrode. The reference electrode must be able to donate or accept fractional charges of electrons in order to be able to charge a counter electrode. And we should be able to potentially start our cell with the help of the reference electrode. Ideally, this will be also only a spectator, so a computational device which allows us to charge our interface and to maintain a constant potential. So it will be something which has a small surface dipole is inert to absorption reactions and so on. So really, it's just there to help us control our interface, the interface we are interested in. And so the questions that we need to answer by building up such an electrochemical cell that we want to use in computation is, first of all, how do we get a reference electrode which allows us to charge the counter electrode, the working electrode? And how do we build that potency start? Here is once more in a cartoon way shown what we want to do. So we have our working electrode. In the cases I'm going to show, it is a metal. But in principle, there is nothing which stops us from having here also semiconductor. We have a reference electrode which is there in order to change charge with the working electrode so that we can reach a situation in which we have a different potential on one side and the other basically potential drop at the interface and electric field trying to solve. Now, the difficulty when it comes to modeling or setting up such a calculation is that typically this is the supercell I would set up. I have my working electrode. I have water and I have a counter electrode. But usually we're working with periodic boundary conditions codes. What does it mean? Most of the DFT codes we are using have really periodic repetition of the cells with that up in all three directions. This means that if I achieve even in my cell kind of this potential drop, so having the working and the counter electrode in different potentials and the periodic image I have again to have the same kind of potential on the right on the left side. Fortunately, this is something we know how to deal with because already many years ago, Neugebau and Schaeffler proposed a dipole correction which allows us to maintain a flatband potential in a vacuum region and in this way really achieve the situation that we want to have. There is, however, second difficulties and I think this was mentioned earlier in one of the talks, the mandatory condition to have a constant Fermi level throughout the cell. What does this mean? That we may set up our calculation having a working electrode and a reference electrode, for example, both of them metals. We run our self-consistent cycle and in the end we end up with one Fermi energy which effectively removes this potential drop. We realized this early on and we thought, okay, can't we use a semiconductor counter electrode and use semiconductor concepts to tune the Fermi level? Afterwards, after all, it is the kind of daily business of semiconductor device physics to tune the Fermi level. How does it work? So if I have here a semiconductor reference electrode, I can, for example, we can have P-doping. This would mean because of the calibration of the Fermi level, there will be an electron transfer from the working electrode to the reference electrode. We will achieve this difference, discharging of the two electrodes. We will have a few throughout the cell and they will be different potential conditions. What is complicated is what material we should choose. And this was a challenging process. So let us look at what do we want from our reference electrode. Ideally it will have a very large band gap and we know that our functionals in DFT underestimate the band gaps. We have also to consider, you saw the supercell I was showing that both the working electrode and the reference electrode are in one cell, which means that they have to be let to smash. And if we deform a semiconductor, of course, the band gap will also be usually influenced. So what we want is to have a material which will have an extremely small deformation potential so that we don't further reduce the band gap as compared to what it is already reduced. We would also like to have a material which ideally straddles the valence and condition band of water so that we can access the whole window of water and not have kind of spurious reaction on this side. And as I said, it should be inert to reactions with the solvent molecules. After some search, we came up with a somewhat unusual choice, which was Neon. Neon is the material which has the largest band gap of the crystal known in nature. And even in DFT with GGA functional, it is something like 11 EV, which was still big enough for our purposes. Additionally, Neon is a van der Waals bonded material. So deformation basically do not influence the band gap. And so we can very easily adapt it in our cell to the geometry that we want and we still maintain the band gap. And it also is straddling the band gap of water in the way we want it so that we can really use it. So we have now find an electrode, which will allow us to set up such a potential stud supercell. And here it is once more put everything together. So we have a working electrode. We have a counter electrode, which is Neon. We have the electrolyte sandwich in between. We have a vacuum region in which we apply a dipole correction in order to ensure a flat band potential. And the additional advantages that we can hear immediately read out the applied bias. I haven't said anything about how we do the charging. So we employed the concept of pseudo atoms, which is something that is very often used in semiconductor physics calculations. Probably most of you have heard about pseudo hydrogens. So these are objects in which both the valence and the core charge are changed by some charge. So this is a neutral object, but then we can have charge transfer from one side to the other. All elements in these setups are really very easily to use in a standard DFT code. The advantages that it works both with semiconductors and metals. And it gives us direct access to the applied bias and the electrode charge. I'll have to come up with this setup. We now have to make a potential start, which means that we want to maintain a certain applied voltage throughout our calculation. And we have recently developed an Appianizio thermal potential start. And in this context, I would particularly like to mention Stefan Wittmann and Florian Dysenbeck, who were instrumental in the development. One thing we have to consider when building up such a thermal potential start is that whenever we change the potential of the capacitive system, this is always a dissipated process. Which means that if we only adapt the electrode charge to control the voltage, we drain energy from the system. This can be nicely seen here in the spot, which shows the temperature development as a function of the simulation time that we use here. We use an empirical tip-trip water model in order to do the simulation. One can see that we basically cool down our system. So we have always to have also fluctuating term, which replenishes the energy within the system in order to avoid this energy drain. And this allows us then to really maintain the potential or the temperature within the system. So we must be able to basically also potency start our system, sorry, the thermal start our system via the potency start. In order to do this, so the way we control our electrode charge is by, or how we derived the electrode charge control was by using the situation dissipation to you. We have a dissipative term, which is a deterministic term. It's equivalent to almost low and dominates far from equilibrium. Basically drives our system towards the target potential with a certain relaxation time time. We have also fluctuation term, which is a stochastic term. It provides the thermal fluctuations. It is dominant when once we're close to the target potential, so the system is close to equilibrium. And it ensures that we correctly sample the thermodynamic equilibrium. We correctly sample the canonical and sample close to thermodynamic equilibrium. This is a stochastic differential equation. And in order to solve it, Stefan used each calculus. I must admit I've never heard about this one before. But in the end, what we call, what we end up with is a comparatively simple equation in which all quantities can be easily obtained from density functional theory. And the electrode charge can be directly computed at each empty steps. And also it is rather simple and can be really easily included in any DFT code capable of molecular dynamic simulations. We have meanwhile implementations, which are working in bus and in lens. And this is something Florian did with a PhD student in Stefan's group. Now, let me now turn towards the application. And the first interface I would like to talk about is the platinum water interface and the increasing hydrogen coverage. This interface is, well, this system is a very nice model system. It has some, of course, relevance for industry, which is always nice because of the hydrogen evolution reaction. But because it is also so highly studied, there is a lot of experimental intellectual work and it allows us to work really at basic processes there. You have already seen cyclical thermograms throughout this conference. So this is a cyclical thermogram for the platinum water system. And what was our interest then? So within this region, you see the potential of zero charge. So basically just the bare platinum surface in contact with water. And along this branch, there is hydrogen absorption. Along this branch, there is hydrogen desorption. And you see that it seems to be extremely reversible. What was also interesting for us that there seems to be maximum coverage that can be reached with hydrogen adsorption on the surface, which is around 66 monolayers coverage. And afterwards, hydrogen evolution starts. So what we wanted to understand is what determines this maximum coverage? So what leads to this onset of the hydrogen evolution reaction and why couldn't this be explained in surface science approaches? So basically, if we neglect to walk it. In order to do this, we performed density functional theory calculations for this interface. We use for the experts RTVE functional, which is VGA functional. And we looked, first of all, just at the work function change in vacuum as we put more and more hydrogen in the surface. I would like to point out that our reference here is just the work function of the P-platinum surface. And what we see is that we follow with our calculated work functions very closely to the experimental measurements. And most of this work function is determined, of course, by the surface cycle change at the interface between the electrode and the vacuum region. If one adds water, then something happens. So these are experimental values which were taken extracted from the work of Markovic. And first of all, we see that we have a very similar kind of dependence on the work function change or electrode potential change with the hydrogen coverage. If we simply shift this curve, you can see that it almost falls on top of the calculations that will perform for vacuum. So this may indicate that water isn't really playing such a big role here. But on the other side, we also see that we don't go quite as far as in vacuum, so we don't seem to be able to reach one moment. So what is going on? In order to understand this, we now added water to the system and now look at the platinum water interface and add hydrogen to it. Different coverages, this is the green curve and you can see the coverages we have actually calculated. Let us try to take this a bit apart. So first of all, if we look at the zero coverage case, this should be just the potential of zero charge. So basically we have the rearrangement of the water close to the interface. As the more hydrogen is added, there is a change in the potential, so potential drop. And so the hydrogen that is absorbed at the interface seems to be able to screen the charge on the metal electrode. But this works only to a certain region. So potentials that are going beyond this point, so beyond the coverage of 66 monolayers in experiment, apparently just absorbing hydrogen on the surface is no longer sufficient to screen the potential. And what happens is that hydrogen in the starts to dissolve and in this way realizes the screening and can adapt to a higher potential. Indeed, when we look at our calculations at one monolayer coverage, we find after about 20 picoseconds that there is a desorption process. So we form here a hydronium ion and this leads to a tremendous drop in the electrode potential. So this kind of structure seems to be all metastable and within our calculation of time, we could see this process for the one monolayer cases. We find also rather slow convergence of these structures that we have looked at here. And quite obvious, we do have some kind of change in the behavior within this region. Trying to further understand this, we now decompose the electrode potential into various parts. So the one part is related to the absorption of hydrogen to the surface. So this is a contribution that we have also in the vacuum. And indeed, if we put this curve on top of the previous curves that we calculated from vacuum, you can see that it kind of nicely follows. When we look about a metal water interface, however, there are two additional contributions which are contributed to the presence of the water. One of them is related to rearrangements in the electronic charge at the interface. So this would be, for example, the charge transfer from electrons from the specifically absorbed water molecules which were mentioned already in June Chen's talk. I guess it was yesterday if I'm not mistaken, but also any kind of polarization effects. And there are effects that are related just to the reorientation of water molecules both to the interface. If you look now at first of all, this electronic contribution as a function of the coverage of chemical water, we see that there is a linear behavior which indicates that each chemical water induces an almost constant dipole moment independent of the coverage. We also see that as the hydrogen coverage increases, the number of chemical water molecules decreases. So if we turn again to this kind of plot where we thought the electrode potential contribution as a function of coverage, there seems to be kind of a transition. So up to approximately half a monolayer coverage, the two water-related orientations almost cancel each other. So they have opposite contributions and they cancel each other. The only thing that they lead to is a kind of shift of this curve which we also find from the picture. The time coverage is of hydrogen. They no longer cancel each other. So there is a contribution also from the water-induced changes in the electrode potential which are of course then reflected in output. So what we can say that at low-coverage is the net water impact is small. Why at high-coverage is the water impact dominates? So it seems that this competition between water-coated absorption and hydrogen-coated absorption is a critical mechanism to understand the electrode potential and the onset of the electrochemical reactions. Because density functional theory of course allows us to further analyze the system and look at the electronic structure, this is exactly what we did. And here what you can see is charge density difference plots for various coverages. And here on the side, we have also taken, so these are two top views and this is a side view just of the platinum atom from the surface and the water that is sitting exactly on top of it. The conventional picture that we have, so this kind of arrangements that's been discussed before is that there is an interaction between the water one V1 level and the platinum D states which leads to the formation of a bonding and an anti-bonding state. And this is a picture that is known from the literature. However, the conventional model assumes that the Fermi energy is below this Fermi energy, sorry, between the anti-bonding state. And so the charge transfer is directly from the water molecule to the platinum atom below it. Now, we looked actually at the charges that we have and to our astonishment, we found that the platinum atom also uses electrons. So there is not really a charge transfer from the water molecule to the platinum atom directly below it. But what we found that the charge transfer is to neighboring platinum atoms. This was interesting also regarding about how many water molecules we can swap on the surface because this means that each water molecule requires a bigger surface area than just one platinum atom, so that's all. And this reduces the number of absorption sites. We also have to revise our model a little bit because what happens is that the chemical water molecule anti-bonding level is then to the metal sperm energy and this means also that the homo of this chemical water molecule is partially occupied and it becomes metallic. And this means that it will have also different properties in terms of screening. So our revised model for the bonding of the chemical water molecule to the platinum surface is that not only the platinum atom directly below the water molecule is interacting and participating in this bonding but also metal atoms around it. I think discuss this problem, I would like to turn now to a different, this is the corrosion of magnesium. And magnesium is very interesting also, it's alloys for structural application for batteries but also for medical applications. One of the big problems in for magnesium is that it has a very low corrosion resistance. So it is the material that is most susceptible to galvanic corrosion as can be seen here in this galvanic series. There is also a very peculiar observation regarding the corrosion of magnesium that there is a really very violent hydrogen evolution at anodic conditions. Anodic condition means that we have positively polarized metal surface and hydrogen evolution is usually a reaction that is associated with cathodic conditions. But these measurements show that we do have while initially a decrease in the hydrogen evolution. Current density as we go more anodic there is a reversal of the behavior. This was first reported more than 150 years ago but the mechanism wasn't really understood. It is in his puzzle corrosion scientists for a very long time. This is usually referred to as the Amandla's hydrogen evolution or negative difference effect. Now that we can really perform calculations with applied voltage, we thought that this is an interesting system to study and maybe we can provide some insight into what is going on. And first of all, we performed calculations under open circuit conditions without applying any voltage and let the system evolved looking at what is really going on. And you probably maybe you saw in the beginning that there was a water molecule which dissociates here can be seen again and hydrogen then penetrates into the surface or moves along the surface. The way it stays on the surface. And if we plot now the trajectories as a function of the as they both over time we can see what is going on. So we have blended out here all the magnesium trajectories that correspond just to the atoms moving as well as the water trajectories of water molecules that are not directly participating in any kind of reactions in the surface. And only leave here explicitly trajectories for water molecules that are involved in what is happening at the surface. We see this water dissociation and the formation of OH and hydrogen and the hydrogen stays within the magnesium slab and OH remains at the surface. We find also maximum absorption of the third monolayer of hydrogen on the surface. This is consistent with these fundamental mechanisms that we discussed. So obviously by absorbing hydrogen on the surface we can see the system is able to screen all the charge on the metal electrode. So if under open circuit conditions there the maximum coverage that can be reached is one third monolayer. And this is also consistent with other studies. Now, if we apply voltage in principle what one would expect that this function at the surface will no longer be sufficient to maintain the electrode potential and also there will be formation of ions within or there will be ions that come into the solution and we may expect to have some of these in the solution. And this is indeed what we can see. So here you can see molecular dynamics simulation of magnesium water interface in which we see that this magnesium atom dissolves from the surface. What was important was kind of that water molecule sneaks below this magnesium atom and then it cannot kind of return towards the surface. We also looked at the hydrogen evolution reaction and to here we have blended out all the water molecules that are kind of not interesting and only left one water molecule which is participating in the reaction in all the digital mechanism. Again, you see here a plot of the trajectories how they evolve over time. And you can see already this diagram is much richer than what I showed you for the open circuit conditions. We have again water dissociation initially and we have a hydrogen and OH formation. We also see that some of the hydrogen propagates and throughout the water layer in form of hydronium, iron and sundial ions to go to the other side of the cell in order to screen some of the potential. We also see here on several hydrogen evolution reactions. So they are shown here in purple. And when we look at more details of the, so here are a few snapshots of the reactions. What we see that there is a water molecule which interacts with the top hydrogen on the surface and eventually forms an OH and a hydrogen molecule. And this is very reminiscent of the Hirost mechanism which is the usual mechanism known for cathodic polarization. However, in this mechanism, typically an explicit electron is required in order to drive the reaction. And therefore it was never considered in the studies of the anodic corrosion of magnesium. What we propose is somewhat modified reaction mechanism which is based on the observation that the hydrogen atom at the surface is actually negatively charged. And this is a consequence of the high visibility of the magnesium valence electrons which lead also in other cases to somewhat peculiar behavior of magnesium. And in this way, what happens is that the hydrogen itself can provide the electron for this reaction and this is, and then it can kind of happen. With this, I'm already at the end of my presentation and come to the conclusion. So I hope I was able to show you that advancing our methods provide us a new level of realism to describe the double layer electrochemical processes and provide really very valuable insight into what is happening at this interfaces. In particularly, I looked at platinum water interface and the quartz option of hydrogen and discussed the limitations which we have in the surface science approach to the neglected water was hopefully able to convince you that we have an idea of the origin of this maximum adsorbate coverage that can be reached for the hydrogen which is connected to the onset of the hydrogen evolution reaction and the origin of the over potential. And we propose a revised picture for the metal hydrogen bond within this system. In the end, I discussed the atomistic mechanism leading to the anomalous hydrogen evolution or magnesium and also showed you that we can really start to look at the solution processes as we try to system as we can potentially control the system. And all this work can be found in these three papers. And before I finish, I would really like to acknowledge my collaborators. In particular, Suda Chamser and Halal who was a PhD student and is now a postdoc in my group and who performed all the work on platinum and magnesium. Stefan and Florian, I already mentioned and Christoph Freisel was of course, also involved in the work and the twin potentiostat. Mike Finnis was involved in the work on the magnesium corrosion. And to last but not least, I would particularly like the technology of Neugebauer for continuous support and always very insightful and helpful discussions. With this, I'll be, thank you for your attention. I'll be happy to take questions. Thank you very much, Nira. So that was a very nice talk and we already have some questions here. Let me see. So the first one comes from Babu. Herbs, you can... You should now be able to ask your question. Hello, am I... Yes, we can hear you, yes. Yeah, okay. Yeah, first of all, thank you for the nice talk. I just have a very fundamental question. I mean, when you're explaining about the pre-type doping of the reference electrode. So if I understand the pre-type doping simply means the depletion of electrons, right? And so maybe like, can you... Maybe you can explain it one more time again if I missed something, I guess. So basically we realize P or N-type doping by controlling the charge on the neon. So I talked about this pseudo-attempt. So we have pseudo-neon atoms. So if we want to have a P-type doped neon electrode, so let me try not to get into the wrong. We have to have neon in which we... I think we add a little bit additional charge. So this is then trans... No, the other way around. We have to remove some charge so that we get charge transfer from the metal electrode to the neon atom. Sorry, to the neon electrode. So we basically control the doping and make it P or N-type doping by controlling the pseudo-charge on the neon. So if I understand, I mean, so the charge should be transferred from the metal to the neon atoms. Yeah, so let me see if I can go to the picture. This looks like the neon atom will gain the excess electrons. So it should look like N-type doping. So if the neon gets it, then it's N-type doping, then P-type doping. I have to think always in which direction I put it, but basically we really change the charge on the neon. Sorry, here. Okay, okay, this is IU. Okay, so we change the... So we need to take care of... We change the valence charge basically. Of course, if we have a pseudo-atom, this also changes the charge. We have to change also the core charge. So we have a neutral object. And this is very important that we really have a neutral object because then even if we have different charges on the neon, so on the reference electrode and the working electrode, our overall cell is neutral. So we don't have anything like a background charge or something in order to... We don't deal with a charged cell. Okay, okay, thank you. Okay. Okay, so this was also not clear for me. So in the neon, you both subtract this Q from the core and from the pseudo-core if you want, and from the number of electrodes, number of electrodes. Okay.  Usually we don't think really what they are, but they're an object which has, for example, three-quarter charge on the core and three-quarter charge on the valence. And they're used, let's say, to saturate the dangling bonds, but here we kind of misuse this concept, if you wish, in order to do the charging in the cell. I see. Okay, very good. So then there is Deepak Kumar who would like to ask a question. Deepak, are you there? Yes. Nice invitation, so I'm curious like... Hello, we cannot hear you. At least I cannot hear you. During your simulation. Sorry, I didn't get this. Deepak, for some reason we hear you very strangely. Perhaps I can just read the question. Oh, okay. It's kindly comment on the number of interfacial atoms or molecules considered during your simulations. Okay, so I mean in the calculations with both platinum and magnesium, I mean, we're looking at the flat surfaces. We had like 64 water molecules. We had, I think, like always four layers of metal. And we had for platinum, for two or four in magnesium, I'm not sure whether we use in some cases also three layer, but we tested this very carefully. And then we had the neon layer, which basically had always the same number of atoms as in the first metal layer. For the simulations in which we had, I was showing the dissolution. We had a visceral surface. And I think the water molecules were more than a hundred. I don't know the exact number I will have to check. But we always very carefully test also the convergence with respect to cell size to make sure that we kind of can make the confusions that we give. Okay, and one thing which I would like to know is in your calculations, kind of are the usual standard functions good enough? Or did you experience any issues? Yes, there are issues. So I mentioned that for the platinum water interface, we use the RTBE. And this was necessary because the PBE was not good enough. And the reason is simply that, I mean, we know that we underestimate the band gap of water severely. And in most cases, this seems to work if we use GGA because the water stability region, so this was to discuss already with the redox levels, is basically just within the band gap of water. Now what happens in the platinum water system is that the Fermi energy of the platinum is very close to the valence band maximum of water. And as we run DMD, then what can happen is that there is kind of chart sloshing in between these two levels and the population flash. The solution with RTBE was that RTBE describes the Fermi level. So the work function of water a little bit, sorry, platinum a little bit worse than PBE compared to experiment. But it also allowed us by using RTBE and band of valves to go to somewhat lower temperatures. So Axel has a paper in which he discusses all the functionals and I guess they made a recommendation for also describing water to use RTBE and band of valves which gives you also a nice description of the water. So this was our kind of reason to use RTBE in the platinum system. This is still not very good. I mean, we have to use hybrid functionals if we want to describe the water band gap somewhat correctly. And this has, if we are looking sometimes at chart transfer reactions, this may become an issue. For example, if you look just at the chlorine iron in water, then you have to use a hybrid functional if you want to describe, for example, a transition between a neutral and a charged chlorine iron. But we know also that hybrids are not really a good choice when we are thinking about metals. So, and also when we think about semiconductor water interfaces, we may use kind of a different screening parameter in order or may need to use a different alpha parameter in order to describe both the band gap of the semiconductor and the water correctly. So I don't have a good answer there. I think this is something we have to work on and really see whether there is some, I don't know, some molecular U or something which will allow us to do these calculations. But yeah, we have to be just very careful of what we do. Okay. Thank you very much. Are there any further questions? I cannot see any raised hands or questions. So if not, then thank you very much, Mira again. And thank all of you who have contributed to this workshop with very nice talks and so on. And one very important thing which I would like to do before asking the fellow co-organizers for some birds of conclusion is that I would really like to thank all the people who behind the scenes have helped make this workshop successful. So most of all, it's obviously Monika, Victoria and Adriana who in the secretariat of the workshop made all these things which are invisible to us while we give the workshop. But thanks to them, really this was, could run very smoothly. Also my colleagues from the ICTS, so the computer section, Massimo and Walter and so on who all the time are there and then Zoom crashes or so they are always with their hand on the mouse to click on the right button. So all these people who we did not see and who did not talk during the workshop but they made a very good job allowing us to have this quite smoothly. Okay, apart from these things, Nikola, Simone and Laura, do you want to say something more? Maybe I will just add a couple of words. Yes. To thank all the speakers and all the participants who contributed to the discussion and among the four organizers, I was the most skeptical in organizing this meeting as a virtual meeting. And but my fellow organizers were convinced that this was, you need a good idea and I completely changed my mind. And so I thank you all for convincing me that this was a good idea, indeed it was. So yeah, thanks again to all the people who contributed and see you next time. Well, what can I say apart from thank you again and I think we have plenty of food for thought now of how little we understand and how we are progressing but how many open questions there still are and yes, so thank you very much to everybody and hope to see you soon. Yes, thank you also from my side and I hope really to have the next conference in presence in addition to the virtual editions and then you meet you all again in Trieste. Yes, drinking espresso and so on. Yeah, I think really one thing that should be... One or two things which really this week has shown abundantly clear both in experimental and theoretical talks is that A, this is a very relevant topic for the future for the near and further future because the energy topic and the way of how to store energy in chemical bonds this will have to pass through electrochemistry somehow and so I think it was very clear this week that this is all very important. And the other thing is which was also clear is that neither from the theory side nor from the experimental side we already know enough. I mean, there is still a space for a lot a lot of research to understand better this phenomena and because of this, because of the importance because of all the unknowns I'm sure that this community here is not the last time that we all are meeting each other and discussing science, okay? So if there are no other comments from anyone anyone wants to say something? No? Okay, then I thank also all the participants. Yes, sure, Mira. Thank you very much for this really wonderful workshop. It was so nice and for putting it together and really it's one of the very nice virtual workshops I've participated on in and yeah, thank you again. So we... Thank you, I'm happy. We are happy if this is perceived as something useful. Okay, so I wish all of you a very nice weekend and I'm sure we will all meet soon again and thank you also to all the participants who invisibly are behind the scenes listening and for the people who watch the streaming. Okay, thank you very much. Thank you. And goodbye. Bye-bye, bye-bye. Bye-bye.


My name is Julian Yortsoy. I work for the Dell EMC Cloud Platform team. Most of our team is engaged in the Cloud Foundry Diego Volume Services project, which is what I'll be talking about today. Some of you might have already heard some of this, because we kind of go over what exactly is volume services every time. So if you have apologies, I try to make it a little bit shorter every time. So quickly, what we're going to talk about is just what our volume services and how they work in Cloud Foundry, what we've done since maybe the last time you were here. We last presented in Europe at Frankfurt, so we'll talk about what we've done in the past year, what we're planning next, and then page full of resources which you can pick up off of the slide deck after I post it after the conference. And we'll hopefully have some time for questions. So what are volume services? Exactly. Volume services is a framework that allows arbitrary sources of volume data information to be mounted into Cloud Foundry containers. It's also an initial set of implementations for that framework for things like EFS, now Azure File Service, Dell EMC ECS, and existing NFS shares. So just looking at how this works at a very high level, this slide's a little out of date because we no longer have a CC bridge sitting between Cloud Controller and BBS, but the overall gist is still correct. Essentially, this is what Cloud Foundry looks like with no volume services. You've got the Cloud Controller managing things, and it's negotiating with BBS in Diego to place workloads onto Diego cells. So if we look at what volume services adds to this picture, it's a service broker. And you may or may not have gone to some of the talks about the open service broker API, but that has a mechanism in it for service brokers when you bind a service to an application to specify that that binding should have a volume mount, one or more volume mounts associated. Then typically, it's some network volume, which may or may not be provisioned by the service broker. In the case of our NFS one, we just attached a random NFS shares out in the world. But in some of our other service brokers, we actually do the provisioning from the service broker. And finally, a volume driver, and this is a piece that's co-located on the Diego cell. Oh, something's wiggled. We're back. So the volume driver has to be co-located on the cell because that's the piece that actually mounts the volume into the host namespace on the cell so that it can get attached into the container. So how does this create a volume mount in a Cloud Foundry workload? Essentially here, you can see when you create a service instance, the Cloud controller talks to the volume service broker and makes the create service instance called the same one you would for a database or anything else. If it's the kind of service broker that creates a volume, then it'll go off and do that. If it's our EFS broker, it'll go talk to Amazon and tell it to make an elastic file system, for example. Or maybe it just records some information. And then the Cloud controller asks the service broker to bind that service to an application. The service broker comes back with a packet of information that's a volume mount. Hands it back to the Cloud controller. We stashed it away in the Cloud controller database for later. And then when the workload actually starts up, that metadata gets passed through the wrap to our volume manager. And that talks to the volume driver, which is the next piece of the system that knows anything about what this blob of service binding means. And that volume driver goes and does amounts of some sort into the cell OS. And finally, that results in that mounted volume getting passed to a garden when the workload has started up.  So we just add that mounted volume into the list of stuff that gets bind mounted into the container.  So that's kind of roughly how it works. That hasn't really changed in the past, I don't know, year, 18 months, something like that. So what's new? That's supposed to be what this talks about, right? The biggest one is the container storage interface. And some of you might have heard my lightning talk about this yesterday. But if not, the container storage interface is a project that was started about a year ago and has been in active development since early this year. It's a collaboration between all four of the major container orchestrators to come to a standardized interface for volume plugins. So volume services, as you've been maybe using them already in Cloud Foundry, are a combination of an open service broker and a Docker volume plugin. We picked the Docker volume plugin API because it was the only thing resembling a standard at the time that we started this work. But even at that time, we were wishing that there was something a little bit more formally standardized as opposed to just kind of cribbing what Docker did. So that's kind of what this effort is. The goal of the container storage interface is to provide a consistent interface, just like you have with the container networking interface or the open service broker, that will be supported across container orchestrators. And that eventually will allow somebody who's providing volume services to create a single set of plugins that work in Kubernetes, in Cloud Foundry, and Docker, and Meizos. So we've been at this since early 2017. It's now kind of at pre-alpha state. Basically, the container storage interface, similar to what we have in Cloud Foundry, has two components. One is the controller plugin, and you can think of this as sort of a subset of what a service broker does. The controller plugin is responsible for provisioning volumes, and also in the case of things like block volumes, it's responsible for doing attachments between the volume and the VM. So again, if you think of an elastic block volume, the controller plugin would be the bit that talks to AWS to say, hey, attach this block device to this VM. The node plugin is very similar to our volume driver. It has to be co-located on the cell or the VM that's doing the actual work of starting up containers. And that's the one that's responsible for mounting, just like we do in Cloud Foundry volume services. The real benefit from our perspective is it's a lot like what we've got today, but it's standardized. So particularly, if you think about a landscape where you imagine Cloud Foundry co-located with Kubernetes running a set of shared services maybe in the same Bosch environment, you can also imagine that you'll have volume services that work across those two runtimes. So this, like I said, is the way that volume services work in Cloud Foundry today. This should look familiar. We just looked at something that looks very much like this with a service broker and a driver. In the new CSI world, as we've implemented it today, we have essentially a generic service broker that's capable of consuming CSI controller plug-ins. So anybody's random volume plug-in and adding a catalog layer on top of that to facilitate user interaction in a way that makes sense for Cloud Foundry. And then we have a node plug-in taking the place of the volume plug-in, the Docker volume plug-in that we have today. So in one case, we have a service broker sitting on top of the CSI component. In the other case, we have the CSI component replacing the component that we would have previously run. But they serve pretty much exactly the same functions. So the service broker will call into the controller plug-in and ask it to provision volumes. And the node plug-in will take a packet of metadata coming out of Diego and turn that into a volume out that gets consumed by Garden. So CSI support in Cloud Foundry is currently experimental. CSI is still evolving, so it hasn't yet stabilized. We're still making breaking changes to it. And because only shared volumes are supported in Cloud Foundry, today we only support CSI shared volumes. So block devices can't really be attached to containers in Cloud Foundry because we lack the scheduling guarantees that would make it safe to attach a block device to a container. So the same constraint applies to CSI as well. CSI for Kubernetes or Docker will allow you to attach block devices. And in part for that reason, there's a controller publish volume endpoint in CSI that's typically where you would do attachment. We don't today support plugins that have that endpoint because we don't have a good hook. Essentially, we don't know from the context of a service broker in Cloud Foundry when we bind a service to an application which cell it's going to end up on. So from that context, predict where storage should be attached to a VM because we just don't know. Essentially, it goes into the auction process in Diego and gets randomly placed on a cell. So we could eventually hack around that. But at this point, it didn't seem to make sense. And the last point here is the testing so far is limited to local volumes because that's the plugin we created. And so we put that through our pipelines. So moving on to perhaps more practical matters, very recently, we've added Samba SIF support. This actually came out of the Azure development team. So they've built a SIF Samba release that allows you to provision Azure file services in an Azure environment and attach those to your containers running in Cloud Foundry in Azure. They're working on something a little bit like our NFS one where you can bring your own SIF shares and attach to those just like you do today with our NFS broker. And I think they're also building a tile for that. But you can try it today. It's in a Cloud Foundry Git repo. And it's all working. Something else to note is we've added support for CF deployment. So if you're running open source Cloud Foundry and you haven't tried CF deployment and definitely want to do that, it's miles better and easier to deploy than the old CF release CF Diego model. So most of our volume services now have ops files that will allow you to just do a CF deployment and mix in, for example, NFS file service ops file. And then it'll create your CF deployment with all the volume services already set up. It saves you having to do manifest generation and all that other yucky stuff. So if you are still running CF release and Diego release and deploying using manifest generation the way you used to, the other thing we've added in the past year, this isn't really all that new, but I will left it in because it's new since Frankfurt, is the ability to use Bosch add-ons to deploy the driver piece. Because the driver has to be collocated on the Diego cell, it's annoying to mix it into the Diego manifest, especially if you don't have ops files as a mechanism to do that. So Bosch added a nice add-ons feature using Bosch runtime config that allows you to target VMs that have a specific job on them to place other jobs on.  So we say like any VM that's running a rep on it should also get our volume driver. So that's a good mechanism to use for now. I believe Pivotal Cloud Foundry and Opsman are going to adopt this mechanism in order to be able to collocate things on Diego cells going forward. Also new from like a year ago, PCF Dev has local volume release in it. So if you're looking for a way to just try out volume services, you want to create an app that consumes file services that persist across deployments or restarts. PCF Dev is definitely the quickest way to do that because you can just fire it up on your laptop. Local volume release is already in your CF marketplace. So you can just create a service instance and bind it to your app and off you go. And that same app is basically relying on the existence of a directory in the cell environment. So you should be able to write an app in the PCF Dev environment, and then turn around and deploy it to a real cloud with a real volume service. And it should just continue to work. POSIX UID mapping and NFS. This is basically solving this sort of fundamental problem with NFS and Cloud Foundry, which is to say, when you push an app, particularly if it's a build pack app in Cloud Foundry, your app is always going to run as a single arbitrary UID. And most of the time, you don't really have to care about this because most of Cloud Foundry doesn't care about your POSIX UID. But because NFS is old, like really old, NFS relies on UID to figure out who the user is that's doing stuff. So if you imagine an environment where you have some shared volume, and maybe it already exists and you were accessing it from some workload on a VM someplace, or maybe you just created it but you want to access it from multiple applications with heterogeneous access control, having an environment where you don't get to say what UID your app appears as is annoying. So we added a mapping layer into our NFS mounting so that when you bind your application to a volume, you can specify a UID. And we'll intercept the NFS protocol and dub in the UID that you want your user act as. And then on the flip side, we dub that back so that by the time it comes back to your application, it looks like the files you created belong to the running user. We also added LDAP as a way of locking down that mechanism because if you configure Cloud Foundry to just allow people to specify a UID when they run their applications, that means you're trusting the application developer to be the UID they say they are. If you don't have that level of trust, you can lock down what UID your users get to act as by connecting an LDAP server, in which case they have to provide LDAP credentials. And then we'll go look up that user in the LDAP, your Active Directory server, and find out what their actual UID is. So this is a good way of kind of coordinating between your Cloud Foundry environment and whatever your old NFS server is, which is typically locked down with LDAP. So file provisioning support in ECS may or may not be aware, but there's a service broker available for Dell EMC Elastic Cloud Storage. That's primarily an object store, so the first version of the service broker allowed you to create buckets in ECS and bind them to your applications. So then you use the S3 protocol to go add buckets, flee buckets, or add blobs to buckets using the new modern way of doing things. If you're writing an app from scratch, then that's definitely the better way to interact with ECS. If you have criminal code that requires NFS or file access for some reason and for whatever reason, like it's an old library or you're working with other apps that require file drop boxes, then you might want ECS to act as a file store. So we've added support so that when you create a bucket in ECS, you can specify that I want this to have file access, and that'll turn around and enable file access on the bucket, create a user in ECS, map that user to a particular UID, and share it out as NFS, and then we mount it using the same volume driver that we use for regular NFS, attaching as that specific UID. So other stuff in the volume services world, it isn't new. Local volume release is just a nice way of getting it to start, particularly if you're running in Bosch Lite or a single cell deployment. This just provision stuff off the Diego cell file system. It's not really recommended for doing any real, but if you're just experimenting, it's a quick way to experiment because you don't require a file server or anything. It's also a good reference point if you're thinking about making your own volume plugins and you're thinking about doing it in Golang. And then EFS volume release, talked about this a little bit already. This is a service broker and driver for attaching elastic file systems in an AWS deployment. So coming soon, stuff is on our roadmap, some enhancements to NFS. Right now, we don't support NFS for, and we don't have good locking support in NFS. Both these things are a bit tricky for some people, particularly if you're looking for better performance. So we're looking to enhance that release. We're lining up some enhancements to the EFS service, including support for multiple AZ deployments. Right now, we only create a mount point in a single AZ around a single subnet if you're deployed across multiple AZs. That means that only if you get lucky in your app placement will you get good performance between the application and your elastic file system. So we're looking to expand that out so that you can have mount points in multiple AZs and get good performance no matter where your app lands. And a CF pushable service broker. Today, the EFS service broker deploys to a VM. We found a lot of people don't like that because it's just another VM and another IP address that they have to provision. So we're looking to fix that. Windows support is coming. We started doing the initial spade work for this a couple weeks ago. But we're looking to essentially take all of the same capabilities that we have in Linux cells and apply them to Windows cells so that Windows workloads can mount SIFS volumes and NFS volumes. And then, finally, support for other volume protocols. I mentioned this already. For SIFSamba, we have coming very soon existing shared volume support for SIFS in a Linux environment. And then potentially based on requirements, there's a bunch of other protocols that we can add support for like SSH or FTPFS or HDFS. So just some quick references. If you're looking to try it out, like I said, local volume release is a good first step. And you can pull down PCF Dev here and get up and running with local volume release already installed. For further information, here's a whole bunch of links. And again, I'll publish this slide deck so you don't need to take a picture of it. This has our Slack channel, our CI pipeline, Tracker backlog, various releases, so everything you need in order to kind of get started or get in touch with us is here. If you have any interest in making your own service brokers and drivers, these are links to the foundational specs that you need in order to do those things and some examples. It's pretty straightforward. So if you were all inclined to do this, then we'd be happy to work with you to get going. And whoop, oh, it's like definitely if you're thinking about making a volume driver or something, let us know and we'll work with you. So that's all I have. Looks like we've got time for some questions. If anybody has any, yeah, go ahead. What about your slides will be available? Yeah, I haven't published them yet, but I'll poke them up there in the next day or two. So if you look back on the Cloud Foundry schedule, you should be able to find them. We were talking yesterday about Kubernetes becoming container runtime for Cloud Foundry. And application runtime basically is obviously garden branchy in every case of deployments. Kubernetes exposes stateful sets for pods with persistent storage. And volume manager, which we are using ourselves, basically does not the same thing technically, but is the same functionality. And I was just confused by having in the same user experience with Cloud Control and everything else, having two ways maybe to deal with persistent storage. Because we told to our users all the time that, apart from specific use cases, going to containerized application was the best way to have persistent storage. So how do you plan or is there any plan to combine with persistent storage from Kubernetes? Yeah, so a couple, I think I heard that question and I heard them not really answer it, a couple notes on that. One is, you might have noticed that we really only support shared volumes in Cloud Foundry. And at various times in our kind of what we're going to maybe do next slides, we've talked about adding block storage or single attached storage to Cloud Foundry runtimes. I think now that we are in this new living in the new world with Kubernetes landscape, that's probably not going to happen. So essentially, Cloud Foundry persistence will be limited to shared volume storage. And there's a class of applications for which that kind of makes sense, where maybe you just need a simple inbox type interface for your application where you look for files in a place. And then if they show up, you pick them up and do a thing to them and you put them in some other place, right? And there's tons of applications like that. And for those applications, if all you need is just an inbox, then Kubernetes is kind of a bit heavy and sticky for you. So the application runtime might still be a better choice. So I don't think we will discontinue support for it. So the other note I would make is that as we move toward the container storage interface, we'll have a much more uniform interface to the volumes of services that we support so you can imagine them being available in the same environment along with Kubernetes. So if it's a shared volume, you may very well have the same shared volume mounted by Kubernetes and Cloud Foundry through the same service broker. So it isn't really exactly an answer. Yeah, yeah, absolutely. We don't have any plans to discontinue it. In fact, I think we continue to enhance it. We're actually seeing, in spite of the fact that Kubernetes is now a thing in Cloud Foundry, we're seeing quite a lot of traction for shared volumes with the elastic runtime. So anything else? OK, thanks very much. Thank you. Thank you.