 So, let me see if everyone is on mute, except you, Rash. Okay, we're good. So please, the stage is yours. Thanks, Rash. Thanks so much. Let me first of all start by saying a big thank you and congratulations to Antimo and the rest of the organizing team for putting together such a wonderful school this week and also a really wonderful developers workshop next week, which I'm really looking forward to being there in person. So thank you, Antimo and the team. It looks absolutely fantastic. So even though I'm not there with you in person, I'm there with you in spirit. I have my ICTP mug from which I'm drinking my tea, but I really wish I was there to join you for this. I'm gonna give you a short talk which really serves an introduction to the hands-on workshop later this afternoon. So I'll give the first part, which is sort of a broader introduction, and then Jonathan Yates will give the second part with more details of how to actually run a Vanie 90 calculation. So my part should take about 20, 25 minutes and then Jonathan will speak after that. So I'll start by first saying thank you to my co-developers of the Vanie code. Here they are. But actually, as I'll explain a bit later, we now have a global community of contributors to the Vanie 90 code. And this has been a really wonderful move that we've made over the, well it was about six years ago now. And I think it's resulted in a real injection of vitality and activity in the development of the code and the surrounding ecosystem of codes. For those of you who are relatively new, the website, www.vanie.org, has a lot of information that will be useful to you. And I encourage you to have a look at that. So the first thing you see here on the front page is the announcement of the summer school. This is where we're all at. If I go to the download tab, this is where you can download the latest stable release of the code, which is version 3.1. It's the version that we'll be using in the tutorials later. This was released in March 2020. So you can download it there if you need to run it on your own machine. Of course, for the tutorial this afternoon, it's already installed on the virtual machine. And there's a link to the GitHub site where the code repository sits for those who want to get more involved in developing and contributing to the code. If you go to the support tab, this is where you can find the user guide and the tutorial set. And also thanks to Valerio Vitale, who I believe is in the audience. He's written a booklet of all the solutions to the set of tutorials, which is very useful for when you're going through it. So again, this is a useful resource. And then down here on the community email forum, you can subscribe to the mailing list where the whole community can answer questions that you have about the code. If something's not working, if you don't know how to do something, there's a very supportive community out there who will probably know the answer to your question. Finally, if you write a paper that arises from using Valerio 90, please do cite the relevant paper. So this paper here at the top, if it's version three or later, or this paper down here, if it's an earlier version, because this is a really great way of giving recognition to all these people who have been contributing and working hard to make sure the code is robust and works really well. So that would be really great. All right, so as Nicola mentioned in his excellent talk this morning and also Raffaella in the talk before, many of functions are used to give a localized and real space intuitive picture of chemical bonding in materials and molecules. And they have links to the modern theory of polarization, lawful magnetization. You can use them as a minimal basis to do efficient interpolation to calculate transport properties and topological properties and very face properties. So they're extremely useful and these days they sort of form part of the standard toolkit of the electronic structure theorist who is looking at solving and understanding problems in materials and molecules. And sort of an overview of how you go about doing this is you start from an electronic ground state first principles calculation using your favorite code. It could be quantum espresso or VASP or Abenet, sort of a plain wave pseudo potential density functional theory code, or it could be something else, it doesn't have to be that. And you get your eigenstates and eigenvalues. And from those, if you need to you can select a subspace of states usually by defining energy windows in your band structure and you conduct this unitary transformation which Nicola talked about earlier this morning in order to rotate the basis to obtain these maximally localized value functions. These unitary transformations are arbitrary and you choose the U matrix which minimizes the total spread of the set of any functions that you want to obtain. So that's how you break the degeneracy if you like in how to choose the elements of the unitary matrix. And so that's what the code effectively does. It does it in a discretized space. So of course, we always discretize our Brolin zone into a set of k points, a measure of k points. And the key quantities that you need in order to conduct this subspace selection and unitary transformation are the overlaps of the periodic parts of the block states, these UMKs on neighboring k points. So the vector B is a vector that takes you from a k point k to its neighbor k plus B. And so you get the first principles code to calculate these overlaps. And Vania 90 reads those overlaps and from those is able to do this. The other ingredient that Vania 90 needs is an initial guess for this U matrix to start off the optimization procedure of the total spread. And usually what you would do is you would construct that initial guess by making an initial guess for the Vania functions themselves. We call these projections, these G of R's. These are usually localized functions that you choose the shape and location of in Vania 90. In Vania 90, you can choose from S orbitals, P orbitals, D orbitals, F orbitals and a bunch of defined hybrid type orbitals. And you put these where you think your Vania functions will be and you project the block eigenstates onto those projection functions to generate a matrix which we call A. And again, this is something that's calculated as part of the ab initio code, is something that the ab initio code typically does for you. And again, Vania 90 reads that matrix in and from that constructs this initial guess for the unitary transformations. More recently, and there'll be a session on this later in the week, you can use the selected columns of the density matrix approach in order to circumvent this requirement to explicitly specify an initial guess for the projections. And this is particularly useful when you're doing high throughput calculations where you can't really by hand manually go and choose the initial guess for every system that you want to study. So that's something you'll hear about later in the week. Okay, so Vania 90, once it's armed with these matrices and the eigenvalues of the block eigenstates, it can go away and minimize the spread and calculate the Vania functions in real space. So from the very beginning, when we started to think about designing and developing Vania 90, we wanted it to be modular. We wanted it to be written in Fortran. Back then, Fortran was really the clearest choice of programming language for numerical methods. We wanted it to be very well documented and commented because even back then we had this idea that we hoped that the code that we were developing for our own research would actually also be useful for other people. It's open source under the version two of the GNU public license. And it's always been under a version control repository. These days it's GitHub and I'll describe that a little bit later. And sort of two sort of overarching ideas that we had was that we wanted it really to be as easy as possible for someone else to come to the code and add new functionality. So that was what was driving a lot of these decisions up here in black. And we wanted it to be very easy to interface any first principles electronic structure code to Vania 90. And for this reason, we sort of took the explicit decision not to include any information for Vania 90 not to require any information about the underlying basis set or the FFT grid that the electronic structure code uses. We only require the matrix elements. So the scalar quantities that you calculate from the eigenstates which are represented in some basis set. So those were sort of very clear upfront design decisions that we made. And I think those were good decisions in the end because as we can see now, there is this very vibrant ecosystem of first principles electronic structure codes that are interfaced to Vania 90. So Vania 90 can read inputs essentially from all of these codes down here with the red arrows at the bottom which really do represent the vast majority of first principles electronic structure codes in our field. So essentially anyone in our community has access to the functionality of Vania 90 through these codes. And then this second ecosystem of codes that use the results of Vania 90 to then do all sorts of other wonderful things many of which you will see as part of this school. So electron phonon coupling, you'll see very properties you'll see and so forth. So it really is a very vibrant and large community and ecosystem of methods and codes. So it's really wonderful to see this. In the early days, the development model of Vania 90 was very simple. There was a small Vania developers group and we would make all the changes and push them to the main code. And essentially we were, this was it, it was a handful of people. And I think I have a photo, I have a photo of the very first Vania 90 developers meeting. So this is Jonathan Yates and me in San Francisco in March, 2006. As Nicola mentioned earlier, Jonathan was a postdoc with Ivo Souza. In Berkeley, I was a postdoc, Nicola at MIT. And Jonathan and I got together and took the codes actually that Nicola and Ivo and David had written in Fortran 77 as part of their earlier work. And we started thinking about making something that was easily interface support to other codes and something that was maybe perhaps just a little bit more user friendly. So I went over to San Francisco and we sort of, this is really the first Vania 90 developer meeting. And this is the picture of the blackboard probably at some point in the middle of the week when we were breaking the back of this. Things have moved on since then. And we now have this global community of Vania contributors. The Vania code is now publicly hosted on GitHub where anyone can contribute code to it. And so the model now is that we have this global community who develop code, make pull requests, which still there's a relatively small group of people that sort of vet those pull requests, make sure that they conform to the style that we require in the code, make sure that things are working correctly, that the structure is okay and compatible with what we have. But then those developments from the community get merged into the main code. And this really happened in September, 2016, or in the run up September 2016 when we had this first community developers workshop in San Sebastian, which was hosted by Evo Suza. And this event led to a number of new developments. It led to version three of the code which was released shortly after that meeting, well, a few years after that meeting and this paper with the full list of contributors to that code. So this was a really great thing that happened. The current distribution is 172 megabits the majority of that is really just examples and the test suite. So this is the suite of examples that the code is tested on to make sure that any changes that are made to it don't break anything. The source code itself is relatively small. It's only 1.6 megabytes of this distribution. And it consists of about 40,000 lines of code including all the comments. So it's still a relatively compact code. Which again, for those of you who are thinking of making contributions and developments, it's a fairly easy code to become familiar with. The code is actually consists of, it actually consists of two parts. There's the main Vanier 90 executable which you can run in either serial or parallel which does the core job of minimizing the spread and in addition to that, you can do some plotting of the Vanier functions themselves a little bit of band interpolation and Fermi surface plotting. You can print out the real space Hamiltonian for you and it does quantum transport. And then there's a second executable post Vanier 90.x which is also serial or parallel and all the other properties including a reproduction of some of these. So it also does band interpolation and Fermi surface plotting and the Hamiltonian. All the other properties are within this post Vanier 90 code. And so the idea is that you would use Vanier 90 to generate the Vanier functions and then you would use post Vanier 90 as a separate step in order to calculate properties from those Vanier functions. And all you need are Fortran compiler, some linear algebra libraries basic linear algebra libraries, MPI if you want to run in parallel and gonna make to compile the code. And here's a list of the user features, the things that you can do with it. Many of these, I won't go through all of them but many of these you will see in later parts of this school and you'll be able to get your hands on calculating a lot of these properties as you go through the school. So I'll quickly just skip through that. But you can see it's already quite extensive and this is not including the ecosystem of codes but then take the results of Vanier 90 and then do further things with them so that all that stuff is on top. And then if you're thinking of developing code for Vanier 90 then here's some information that might be of interest to you. So as I've said, it's under GitHub and we operate a fork and pull request model which means you should fork the code into your own repository, make your changes there and then do a pull request into the develop branch which will then be checked. We have a suite of tests which check the veracity of the code both for pull requests and also sort of regularly just to check that things are working okay. The continuous integration is done within GitHub Actions. Used to be Travis CI but we changed that relatively recently. If a commit doesn't pass the tests then it's blocked and it needs to be fixed. And there's a few other things that might be of interest to developers which I just mentioned there. One thing that is a fairly major change that will be coming soon is this distinction between what we call the standalone mode and the library mode. And this is the last thing I'll mention in the talk before passing to Jonathan. So standalone mode is probably the mode that most people use Vania 90 in. So it's essentially, you treat the electronic structure code or the post-processing code as an external program and Vania 90 as an external program. So the two programs are sort of separate. The two codes are separate and they talk to each other by reading and writing files to disk. So let's say this external program is Quantum Espresso and Vania 90 needs to tell Quantum Espresso what overlaps between the block states to calculate. Vania 90 will write a file to disk. Quantum Espresso will read that file, calculate the overlaps, write them to file again and then Vania 90 will read those overlaps in. So this is what we refer to as standalone mode. So all the communication is done via files written to disk. There is also a, and this is sort of in detail how that works. I'll just skip that for now. There is also a library mode where the external program calls Vania 90 from within itself. So there are, in particular, at the moment, there are these two library calls that you can compile within Vania 90 and then use them within your external program to call the functionality of Vania 90. So this first library call will do the setup. So it will tell your program, for example, which overlaps it needs to calculate and all the things that Vania 90 needs to generate the Vania functions. And then you call Vania Run to actually calculate whatever properties you require. Now the current version of the library is quite rudimentary in the sense that it's serial only and it only has a subset of the full functionality of the full code. In particular, it really only does the core disentanglement and vanearization, nothing else really. And this library mode hasn't really changed for many, many years, really since when it was first implemented at the very beginning. We're currently undergoing a major efforts which is funded by the UK's Engineering and Physical Researchers Council, Physical Science Council and the UK's CCP9 network, which is sort of the UK's internal electronic structure network to really transform Vania 90's library mode such that it incorporates all of the functionality of the code. And in fact, Vania 90, the program itself really just becomes a wrapper calling its own library. So that's the aim. And the idea behind this is that it will enable external codes, full access to Vania 90's functionality by calling the library from within themselves. And this has lots of advantages because it will enable Vania functions to be accessed, for example, during a self-consistent field cycle and electronic structure simulation. Say at each iteration, you can monitor, say, the polarization of your box of water molecules we were talking about earlier. Let's say you're doing a dynamical simulation of that. And if you can call it from within the code without having to go to an external call of Vania 90, you can monitor these things on the fly. You can run multiple instances of Vania 90 simultaneously from within your code with different input parameters, for example. So there are many advantages to doing this. And so we're now progressing towards that goal. There's already been quite a lot of progress over the past 12 or 18 months for those of you who've been following it. And we're getting closer to it. It's going to be one of the major topics of discussion in next week's developer meeting as well. So I just thought I'd mention this is one of the main upcoming developments from our side. Right, I think I'll finish there. And I don't know whether, and Timo, you want to do questions now or do questions after Jonathan's talk for both of us? I think we can take questions now while Jonathan prepares all his presentations, essentially. So let me just see if Jonathan is connected. Yeah, okay, yeah. So in the meantime, do you have any questions here in presence? Raise your hand. Are there any questions on Zoom? Write in the chat or raise your hand virtually, let's say. Okay, so maybe I have a question. So Rash, can you hear me? I can, yes. So this looks like a major change, going from a code that is supposed to be mostly standalone to something that is mostly a library and then use it. As you said, you just write a wrapper. So how do you plan the transition for the users? How is it going to work? Is it going to be like a version 4.0 where all of a sudden everything is encapsulated as a wrapper? Yeah, so that's a really good question. I mean, I'm hoping that for users that will use it as a... who use BANI90 as a standalone program and will continue to use it as a standalone program, the impact should be minimal. For developers, obviously a lot has already changed and a lot will change internally. And so people who are developing contributions need to be mindful of the changes that we're doing. And in fact, I didn't mention it, but we've been doing these developments hand in hand with the community. So there's been... even before we started, there was a huge amount of community engagement with the developer community. We wrote to all of the developers of codes within the ecosystem, asked their opinions of what they thought about moving to a library, what are the main features that we should make sure that we have. So it's all been done hand in hand. We have a wiki page on GitHub which is sort of explaining the stages that we're doing in the development and the timeline for those stages so that people are aware. So we're very aware of the impact on the developer community. And this is why it's going to be one of the big topic of discussion next week, I think, to just make sure that we're bringing people along with us and not causing too many headaches. But yes, there obviously will be a few teething problems in the transition, I think, in particular for developers. But I think the place we're going to be at afterwards will be a better place. So I think it's going to be worth the efforts. Absolutely. Thanks a lot for the clarification. So I see there is a question from Steppan. Hold on a second, I'll bring the microphone to him. Hello, Arash. My question is, all these changes in the library mode, are they only for one year 90 or for including post-w90? Yes. So the idea is that it will be post-w90 as well. The stage we're at now is we actually need to think about how to structure the library calls. So it's not going to be one monolithic library call. We need to think about what are the library calls going to be? How are we going to divide that up? And so this is, I hope, one of the things that we're going to discuss next week in detail. Okay. So if there are no any other questions, I think we can thank Arash for the great talk. I moved to the second part. So we have Jonathan Yates who will be speaking about one year 90, a brief overview of the call. So the floor is yours. Jonathan, please. I can just check that you can hear me, okay? Absolutely. Loud and clear. Brilliant. Thank you. Okay. Well, welcome everyone. So thank you to the organisers. Obviously I can't be in interest at the moment. I'm still in the UK. I'm looking forward to coming to trust for the developer week next week. So in the remaining time before lunch, it falls to me to talk a little bit about the practicalities of running a code. So I'm going to talk a little bit about the way to run a code. That's a little bit of a weird thing because the way to get used to running a code is to dive in and run the code. But this afternoon there will be the opportunity to do that. We've got some fairly in-depth tutorials to guide you through. There are lots of people that you can talk to and ask questions. And I spent part of the weekend making a series of YouTube videos about how to run a code. It's useful as a bit of a taste to give you some of the principles of how Vania 90 operates. So what are we going to take as the input? As Arash mentioned, we need three inputs into the Vania 90 calculation. They might have been generated from Quantum Express though, but they could have come from electronic structure codes like the M matrix, M, MN, which would be the overlap U, M, K, U, N, K, plus B. These are the overlaps between block states at a K point and at the nearest neighbor K points. We'd have some projections. This is the A matrix, A, M, N, U, G, M, projected onto U, N, K. And then we'd have the IG file, which is the eigenvalues. Those are the inputs for doing your basic Vania calculation. To control Vania 90, we would have the Win file, the Vania input file, and we use the concept of a seed name. For example, we see that all the files here have silicon as their seed name. So we're going to use that to what we would pass to Vania 90 and it would know which files to read. So a little bit more on the input file. So the Vania 90 input file is rather flexible. You can have some comments. So all these different ways choose your favorite way of having a comment. If you need to set a keyword, you can do it in a number of different ways. Okay. The useful one to know about is the I print. So the level of the velocity that gets written out in the output file. So I print one is the normal level. And if you'd like to see lots more information, you can increase that. For example, I print three is the full debug level. Okay. So Vania 90 has lots of different keywords. You don't have to specify all of them by default. The defaults. For most of the keywords, there's just a few that you actually have to specify. So we do need to tell it what the system is. Okay. So here's an input for silicon, for example, with my two atoms of silicon. And here I've given the unit cell in Cartesians. And the default unit for Vania 90 is angstrom. But if you like bore, you can just tell it to use bore instead. So as various of the speakers earlier have talked about, it's very helpful for Vania to have an initial projection onto some local orbitals. So we have a quite flexible way of specifying these projections. So for example, this is for the copper example that the color showed earlier where you put the orbitals onto the copper. And then because we wanted some S orbitals at the interstitial sites, we've given the actual fractional coordinates of the locations of where we want those S orbitals to be. This would be, for example, in silicon if we wanted to project onto SP3 orbitals. And, you know, if you don't want to use a projection at all, you can see what happens if you use just the block phases, so run without any projections. That's likely to lead to quite a long minimization procedure, but in some cases it can be interesting. Controlling the minimization. So we've got this distinction between when we're dealing with an isolated manifold of states. So, for example, the valence bands in an insulator and the more complicated case when we've got an entangled set of bands, for example, a metallic system. So let's just deal, first of all, with a straightforward case. So here I've got the valence bands of silicon. And we need to tell Vania 90 a couple of things. We need to tell it how many silicon for bands or Vania functions. We also need to tell it how many iterations to run for. Now, that's a little bit of a change from if you're used to electronic structure codes, you'd normally ask for a minimization algorithm, you'd normally ask for some sort of tolerance on the total energy convergence, for example. With Vania, for reasons I come into a second, instead we tend to specify the number of the number of iterations. So, that's our inputs. The files we need to read, that's the, yeah, somebody's asked about random auto, okay, there are lots of more sophisticated ways to specify projections. There's some interesting talks coming later this week about more advanced ways to specify projections. I'll leave that for a little bit later. I'll just keep on with the simple calculations onto atomic orbitals, the more old-school way of doing things for the moment, okay. Right, so we've got our input files, the mmn, the amn, and the icfile, which have come from our ab initio code, we've got our Vania input code, and here we have the, what would happen if you run Vania90, so this is part of the output of Vania90, there's a lot of information on there, but this is part of minimization cycle, so this is the first cycle, so this is what happens in the first step, and then this is, well, the initial step before we've minimized everything, and then in the second step, we've done a slightly different unitary transformation, hopefully to make the spread a little bit more localized, okay, and we've chosen that in this kind of contour gradient approach that Nicola referred to. Okay, so this is silicon, we've projected onto, in this particular case, we've projected onto atom centered, sorry, bond centered s-orbitals, and we get the locations of each of these correspond to the four Vania functions, we get the location of the Vania function and its spread, and if you looked at the crystallography of this, they're just distributed on the bond centers, and to good numerical approximation, they all have the same value of the individual spread, so what have we got here, we've got the decomposition into the difference, so this is the total spread here, and as Nicola mentioned, we can have an off diagonal and a diagonal contribution to the spread, okay, and this is the total spread, which is actually the thing that we're minimizing, and so we make this new unitary transformation, and the spread decreases only very slightly, but there's a slight decrease in the spread, this is the first iteration, and that's the delta here is the change in the spread from one iteration to the next, okay, so this will then proceed through a number of different steps, however many we've asked it for, here we go, so in this particular case, 100 cycles later, this is what we're finding that the change in the spread now is really very small, okay, at least it looked like recently well converged, and Vania 91 now finished, plot out its final state, and it will now give you a report on the decomposition of the spread, but again the most interesting one is the total spread here, and just at the time for this, which was 0.2 seconds, okay, sort of within the noise, this is an incredibly fast calculation it's dealing with, with silicon, so lots of 4x4 matrices, so why did we not specify tolerance rather than the number of steps, each step is really very quick, and we find that the minimization can sometimes do things like a plateau, so it's not uncommon to see something like a minimization where it goes down, it plateaus, and then it goes down again, that will happen for example if you start with atomic states, you'd find you'll get yourself into a plateau like this, and then after a few steps the minimization will drop down again and we'll hybridize them into, say, SB3, all the tools or something like this, so our recommendation is actually to pick a number of steps and monitor how the baneurization is going. There's some quite sophisticated restart facilities, so for example you can set the, it writes backups, every few iterations, you can determine how many there are, how often they're written, so you can, for example, run Vania90, quit it, and then you could then restart and do all the plotting if you decided that Vania90 had actually finished and you didn't want to allow it to carry on with the number of iterations, or equally if you run it for 100 iterations and decided it needed more iterations, you can restart and carry on with the baneurization, so there's some good restart features in there. That's, Oscar's got a really good question, which is about how to avoid local minima. I think that that will be better handled a bit towards the end, I think that's because that's a really interesting and important question. Okay, so that's about the job control. So to plot the baneur functions, very straightforward, we have a baneur, we can say that baneur plot is true. The baneur functions, reasons I mentioned in the moment, live within a supercell of the unit cell, so we have to decide how big a supercell to plot. Plotting the baneur functions can be a little bit expensive, so we can actually plot a subset of them if we wanted to, for example, this would allow us to plot the three baneur functions, numbers one, four, and eight. This version would allow us to plot baneur functions one, two, three, four, and six. Okay, so reasons to plot the baneur functions would get pretty pictures, which are good for including talks like this one for silicon. But there's something else that's very useful when we plot the baneur functions is that baneur 90 will allow us to then look at how real the baneur functions are. So here for silicon, we've plotted the maximum imaginary to real ratio, and you see that's really quite small. So what these means is to a good numerical precision, the baneur functions in silicon are indeed real. Just to note, here's the time it took to plot the baneur functions five seconds. To make the baneur functions 0.2 seconds to plot them five seconds. So plotting baneur functions way more expensive because we have to go back to some sort of basis. So we can also plot bands. Simple logical to turn that on is the plot bands keyword and we can set the number of points along each section but then we specify the high symmetry directions. Okay, so this is something you can obtain for your material from materials cloud or secret path for one of those places that allows you to get hold of a sensible path through through case base. And so this will use the the sort of Vanier, the Hamiltonian in the Vanier basis and the idea of Vanier interpolation to very rapidly give you a very detailed band structure. Okay, so just to summarize, there's a bit of a choreography of running Vanier and the ab initio code. So and this can be sped up with things like idea and the things that you might hear about later on, but some the standard way of running it would be first of all we run for good. This is this is an example for quantum espresso, which we've been using the tutorial. So what we would do is first of all, we run pw to get the ground state charge density. We then run quantum espresso again but now we want the block states on a uniform mesh of K points in the Brillouin zone. Okay, and that's going to be a key parameter, whether we choose a 444 mesh of K points, but I'll come on to that in a second. We then run Vanier 90 with this so-called post preprocessing flag here, the minus pp option. What that does is it analyzes the symmetry of the crystal the K point mesh, and it decides what overlaps need to be calculated. So these overlaps between the block states and neighboring K points, it generates an exact list of what it needs, what Vanier 90 will need and it also generates a list of what projections it needs. So then the code pw to Vanier 90, which is part of quantum espresso will calculate those overlaps and projections for us. It will use the block states. We got at this step with the instructions from this step, and this will generate the those matrices we needed the M matrix, the A matrix and it will generate the eigenvalues. Then finally, we can run Vanier 90. Just to say if you want to run Vanier 90 in parallel, it's very easy, you just run it with MPI run and it goes through like this. For the examples you're running this afternoon, they're all quite small like silicon is a 4x4 you know dealing with 4x4 matrices so the parallel performance will actually not be that great. The Vanier calculations themselves should be incredibly quick, so I would probably just keep to the serial version. Just a little note about K point sampling. So in principle when we form the Vanier functions, we should use this continuous integral over the Brouillon zone. A Vanier function then, one Vanier functions lives by itself in infinite space in the crystal. But in practice, we can't do that. We use, we replace the integral with a sum and we do a sum over a finite number of finite grid of K points. And that has an implication for the periodicity of the Vanier functions. They're no longer completely isolated in space. They have periodic images. So for example if I sampled the Brouillon zone with a 3x3x3 sampling, my Vanier functions would be periodic in a 3x3 supercell of the unit cell. And the key thing is the finer the K point sampling the greater the unit cell the larger the unit cell that they live so the further away are the periodic images. You can notice that sometimes when you do plotting because you might think well hang on why am I I got an extra Vanier function over there and what you're seeing is the periodic image. But it also has an implication when you're doing making a Vanier type binding model you're looking at the Hamiltonian of the Vanier function because if you thought about in the infinite case you could have the matrix elements between your Vanier function and any other Vanier function that you wanted that would be nicely well defined. If you had fairly coarse sampling you could certainly have first nearest neighbor interactions you get the Hamiltonian between these two Vanier functions but if you thought about second nearest neighbor interactions well that's a problem because that's the same as first nearest neighbor interactions okay the periodicity doesn't allow you to do that but if you sample more finely in K space and thus push the periodic images further apart you can now have second nearest neighbor interactions as well as first nearest neighbor interactions okay. What does that mean when you're looking for example at the band structures that come out of Vanier 90 well here's an example of lead I know it's a metal but luckily lead has an isolated group of low line bands so we can use the standard techniques that we've used so far even though it is a metal and so if we construct the Vanier functions using the four cubed K mesh and we then look at the Vanier interpolated bands you can see some differences so the blue is the Vanier interpolated the red is from QE and you see that there are definitely some differences in that sort of around here and around here if we increase and we go to a much larger mesh we've got more nearest neighbors in our type binding representation and now by eye you certainly can't see any difference and we can make this more numeric by just calculating the average errors and what you can show is that as you increase the K mesh the accuracy of the Vanier interpolation increases exponentially and that's related to the exponential decay of the Vanier functions so one of the main parameter that you're going to end up potentially changing to improve the quality of Vanier functions will be the K point sampling that you use to construct those Vanier functions but because of the exponential sampling you'll never need to use an enormous K point grid. The last thing to cover is what about a metal? When we have an entangled set of bands this is the situation that Nicola discussed towards the end of his talk so this is where the example might have a so here this is the band structure of copper there's no set of bands that are distinct from all the others so if we wanted to extract out a Vanier basis to describe well for example the Fermi energy is in copper we wanted to extract out a Vanier basis to describe these low lying occupied states or conduction bands we've got to find this method of extracting so for example we might have 12 block states that came from our quantum crystal calculation and we want to extract out seven Vanier functions so we use this method that was introduced by Eva Sosa of minimizing the gauge invariant part of the spread we want to extract out what we call an optimally connected subspace so we have some windows we define we can choose to define anyway an inner window and we say those states we're going to include they're going to be as they are we're not going to allow those states to change they're definitely going to be in our unitary transformation going from the 12 bands into the seven Vanier functions they're going to be in there and this is outer window so these states here we will allow some non integer mixing of those states and we will do that in a way that minimizes the gauge invariant spread so when we're dealing with metals we also have to supply these windows as well as the number of bands and the number of Vanier functions and this will be automatically turned on as soon as the number of bands isn't equal to the number of Vanier functions so we're going to try to choose which states is a really good one and I think the best way to answer this is to say there is a bit of trial and error involved in this you certainly need to plot a band structure from the DFT code first you need to think about the character of the states that are involved and there is a little bit of trial and error you'll see that Nicola mentioned some work and Valeria will talk later in the week about methods to automate this process but at the moment there's a little bit of trial and error in these techniques and I think what will be useful is to do the tutorials and see how we've set it up in the tutorials and get a bit of experience there and then talk with one of the demonstrators someone who's got some experience of extracting Vanier functions and then I think that will be a more productive discussion once you've been able to see it but I will say there's a little bit of trial and error in this process at the moment okay alright let me scroll through so what would happen in this scenario so when we have a we're trying to get a smaller number of Vanier functions than we have Vans we will start off by doing the minimization of the gauge invariance spread the extraction of the optimally connected subspace and this actually does have a tolerance on it so we do tend to run this because we find that this converges if everything is well this converges quite quickly if the windows aren't chosen right we find that this converges very poorly so this is actually quite a good indicator of things so for example this is a minimization of gauge invariance spread that took about 17 steps okay so just to remind us that this is my copper are the last three lines mandatory I think they mean can I go back to my talk do you have to specify the windows no these are not mandatory the user guide is actually really good we're very clear on what you have to put in and what is optional you'll normally end up specifying the windows because you'll find it useful but you don't have to right so that was copper so that's the QE band structure and just to say this is what would have happened at the end of the minimization when we plot out the the Vanier interpolated bands so this was my frozen window down here the Fermi energy is this line over here and you see that all the states are well reproduced inside the inner window that's the area in which they're physical and then outside minimization of the gauge invariance spread has chosen the correct states that essentially carry on the character of the states that are down here so for example did it ignore this state maybe that's got some p-like character that isn't in a Vanier basis and instead it's chosen a more kind of free electron like state that goes up here and down here and these are what the Vanier functions look like five d orbitals and these two interstitial blobs so that's a seven-dimensional Vanier basis for copper okay do I believe the results so in other words have you done a good vanearization is always the question so what are you looking for you're looking for the spread so if you're doing the vanearization part the spread should have converged often in simple systems it might converge to numerical precision but once it's converged to less than 10 to the minus 5 EV that's actually quite well converged it certainly won't make a difference to any properties of the interpolated Hamiltonian you're looking for the individual Vanier function spreads to be small that's a really rough say less than five square angstroms is a really rough rule it's hard to say that but you're looking at quite a small number the vanear functions themselves should be real and you can do that by plotting them at least in the absence of spin or big coupling okay and you should look at the intercalated bands that's really the key thing to make a comparison of just to note quickly that there is the as Arish mentioned there's the post-pressing tool post-provenient 90 you can run that in serial and parallel there are a variety of different properties you can obtain I've focused more on how to get hold of the Vanier functions and of course there are lots of other tools that will run off the back of Vanier 90 and perhaps just to finish just to note a few bits of places for support and advice beyond this workshop the website the user guide we try to document source code reasonably well and we do also have the Vanier 90 main list right that was my whistle stop tour of the Vanier 90 code I'll stop there and take any questions if there are any so I see there are some questions online but maybe let's see if there is okay I see at least two questions in presence let's start from these so the maximally localized when you function have an exponential and as you probably know the paper proving that is almost unreadable now you have shown a very nice exponential plot about the effect of the periodic images can that be taken as a computational proof that the TAs are indeed exponential I've always taken it to be as such it does seem to work out what I was kind of pleased with as well is that the exponential decay happens for if you consider the valence bands in silicon you get this exponential decay but it's also true for Evo's disentangled function so if you form the Vanier functions in metallic systems with Evo's process for doing this disentanglement and then you do the same look at the same convergence property you still get the same exponential decay and I think that's part those Vanier functions may well be outside the kind of formal proofs there was another question up here is it necessary that disentanglement criteria must be satisfied I would say that it's a good thing so one of the things you can play around with in the tutorial is where you choose for example the top of the windows so how many states that you're including for example here so in this particular case if you put your window say there rather than here what you might have found is that it didn't have quite the right state to be able to get very well localised Vanier functions so what you might have found there is that minimisation that we did for the disentanglement of the gauge invariant spread that might have either converged extremely slowly or quite poorly or just not converged at all and then you find that if you look at the band structure and go well hang on if I move my window a bit further up so I can include this extra state then I've somehow got the right character within the set of bands which I'm choosing and the minimisation happens quite nicely so my recommendation is that you should use the initial minimisation as a guide as to how well you've chosen the windows of the states I found a case in which disentanglement criteria is satisfied but I was getting imaginary Hamiltonian part but in the other case where disentanglement was not satisfied but real Hamiltonian part and imaginary is zero so what should we believe like real Hamiltonian must be there so the other case where disentanglement is not satisfied I think that's quite specific and I'd be kind of interested to see your input files and things I wouldn't want to make a very general statement about that I think I'd be just interested to see the files and then I can comment more specifically or any of the demonstrators can probably comment and is it a good idea to increase the number of steps to minimise the spread yeah so it will the algorithms particularly at fine K point meshes so one of my recommendations actually is to always start with a fairly crude K point mesh when you're getting hold of the the vanier functions it may well be that the interpolated bands are not very good they display a lot of oscillation but you'll find that the minimisations work much more efficiently and they can find to the right minima so I normally would start with a very crude K point mesh in order to decide on what my vanier functions should be when I seem to have got good vanier functions with the right kind of properties I'll then increase my initial ab initio mesh in order to get the interpolated properties that I want I was talking about like number of alteration steps yes you sometimes need quite a lot so we can increase it so it means to minimise the spread yeah and how many atoms we can deal with this vanier 90 I think we have time there is an entire afternoon for technical questions I think yeah so maybe Jonathan you can go through the questions that were asked online and see if there is anything you want to answer now or if you want to just I think I got a few of them as I was going through if I ignored any apologies but it was probably because I thought that would be better asked in the tutorial sessions I think I can pick things up in the tutorial sessions so in the of time I think we can stop here we are a bit late on schedule and thanks Jonathan for the great talk