 Yeah, good to go if you're ready on you can get started to other packages and I will show the example of siesta for example You have different packages which also which Which can be used by Abinit and siesta, but of course Both codes have different build systems and different philosophies. So they are there needs to be a bit more than just these very simplistic wrappers and So what what has happened in the last couple of years is To to be able to use different solutions We have started to to improve The build systems and test suites of the packages in In siesta starting with the the common ones that they were for Abinit So now Leap PSML for example as standard build system auto tools based The same we have done the same for LibFDF. LibGridixi is work in progress As well as fluke and other dependencies of course came already with standard build system like Libint or net CDF Also Vanya 90 which is also a common dependency of both was Let's say I I provided already quite some time ago a Standard build system for for it What what also happens With I would say It's not really When you want to generate pseudo potentials for example the You you may use the same program with with Abinit and siesta but in different conditions for example Abinit is able to process the The output of oncv PSP so to use the subbot it potentials generated in the native format of oncv PSP, but siesta Requires a PSML patch What happens is that since Abinit is also able to use the PSML we We want to distribute also the the oncv PSP with the PSML patch and since This is not always trivial to to have everything working after applying this patch so we We want to have an automated Solution and robust solution to do this so just to To summarize what we have so for for Abinit We have Some Some dependencies that here We will exclude for the moment big DFT because The version of big DFT which is used by Abinit is a heavily patched one and so for this we will wait Simple dependency like a tempo can be managed very easily with just one One config file and then Some of the the dependencies of siesta so libGridixi out of interest to other codes, so we We put them as also prioritary and we want first to have the everything working for The common dependency of the code and of course we don't want to to take care of some parts like MPI linear algebra things like HDF 5 or FFT, so we we want something which is Already provided and easy build Actually provides all of these components that we need so removing a lot of complexity From our site to manage so the the efforts Started let's say individually, but they are there are no Perform collaboratively within the electronic structure library, so just for people who do not know about it to to some to to briefly summarize it is it's an initiative which Ames that providing modular software components to To to to either to build a new electronic structure codes or to improve the structure of existing Codes and also to for new commerce to to to reduce the The Sorry the learning is a step that they have to to go through so the DSL works through The usual source code repositories that you can find so now we are moving Most of the code to gitlab.com with mirror in on github Some components are developed through big bucket and launchpad, so it depends on the preference of developers So the SL organizes monthly video conferences and Also yearly coding workshops, which is where most of the of the efforts are Performed so we have very very intensive two weeks usually where we advance most of the ESL projects and also everything can be found on the wiki and Where we will enhance soon things about documentation about good practices and all related topics so the Through the ESL what we do is so we have Since last year What we have called the ESL demonstrator, which is a very small electronic structure code that Uses both plane waves. So like having it or atom centered orbitals like siesta and Which is built from the different components of the ESL which are Where the the dependencies of siesta and abinita included So to To manage the dependencies we are internally we use A bundle that is based on GH build so GH build was the build system of GNOME, but can be also used for More projects with just very little tuning so it proved to be a very interesting solution for us up to now and Since now it's it starts to to be working pretty well we We have started just in our yearly workshop this month. So two weeks ago the repository of easy configs for all these Dependencies that I've shown before So this is still in a relatively early stage so the The the point is to Every six months what we want to do is to produce a release of the ESL bundle so with new versions of the of all these libraries and packages that That I've shown before for a two easy build to a tool chain So the once the ESL bundle is released we produce The the easy configs for the force and Intel So the current one And the we prepare also for the for the upcoming one so we our aim is to release one month before each a new Version of the tool chain will be released by easy build and to to propose to send the pull requests As soon as possible when these tool chains are published and then Yeah on top of the ESL bundle I've started to to maintain also an abinit bundle and a siesta bundle Because the ESL bundle does not contain all the dependencies of abinit and siesta and This is done in a way that it It keeps synchronized always with the ESL bundle so Now we are at the first Release cycle, so we are This time we we won't propose The The easy configs for the force and Intel 2019 a but we are we think that for the 2019 b things will be will be ready and will be able to to include them in In easy build So to summarize the these efforts that started in 2019 into 17 sorry So In 2017 we first implemented a proof of concept in the university of cantabria Where I am now and We have started to share between 2017 and 2019 The the easy configs produced with partners And gathered some feedback And then I started to to submit some pull requests last year To easy build to start collaborating with the developers of easy build and So now just now we have Started this integration phase of easy configs Into the the ESL so the the files are there and you can access them on githlab.com But where then the wheel and it will be In six months that we will be able to To share them with easy build And Next stage will be to start managing abinit and siesta dependencies through Through this this strategy So In In this talk I've so I've I've shown you briefly How we we have gone from ad hoc solutions to manage the dependencies of Electronic structure codes to a global solution That hopefully will be Used Robosely and on the long run And from my side From the The experience I've had with easy build so far I have a little wish list Which is for me the the the most important thing is that It gets proper python 3 support because this is becoming more and more difficult to get To get it working With python 2 on On recent machines And What happens in our hpc cluster is that we We often run out of space because we have a group quota And so that would be nice to to have an uninstall feature in easy build so that We are pretty sure not to remove the wrong files Also Sometimes yeah I've seen that the style of the easy configs is changing Over time and it's not always easy to know which is the most up-to-date best practice For to write new easy configs or to to improve the existing ones And And Yes for easy blocks I also Encounter some issues Writing easy blocks because sometimes I write it on a machine and it works on that machine and I move to another machine and it stops working And I'm not able to always find the why so That would be nice to have some some more information on this Okay, so that's that's all for from my side. So I think I think the organizer for having Given me this opportunity to to share this experience and Thank you for your time Thank you very much, Jan Can you hear me for questions? Yes. Okay excellent. There's a question on the chat And yeah, and actually it's the same question I had as well. So you're collecting these ESL bundled easy configs and the github github repo Yeah, do I get that right that after after six months you plan to contribute them back into the central easy configs repository? Or is that going to keep? Yes, exactly. Exactly. Okay good. So that's that's the That's the point but we want to have them first in a in a repository of our own to test them ourselves So that that means you will always be one generation behind the latest common tool chains or No, what we okay when we When we release the The ESL bundle in principle, it should be one month before the the new easy build tool chain So we we first produce easy configs for the current Toolchain and then when the new toolchain is published one month later, we we will test We will produce the the corresponding easy configs and Test them and send also a pull request for them. Right. So basically you might have two pull requests one when we publish The the ESL bundle for the current tool chains and one month later or one month and a half later Another pull request for the new tool chain, right? So you'll do an update of the tool chain in place and then make sure it work It still works with the new compilers and so on. Yes. Okay. Yeah Yeah, because sometimes we have some very bad surprises with new compilers versions. Yep No kidding indeed. Um, any any other questions in the room? No, I do have a one or two more questions. So Um, it looks like you're trying to convince the the electronic structure code community to Switch or at least adopt easy build for installing all dependencies and the code themselves How much effort did it take to convince people that this was a good idea? Uh, I would say it it depends on how long people have been using A different solution for example for siesta that was not very difficult They they could see the value of it relatively quickly But for abinit, this is still very hard to convince people to uh, that's Uh, to to to give uh, let's say to give up a bit on the abinit fallbacks because it's really deeply entrenched in their habits Okay, and one one more question you mentioned that Um, python 3 support is on the top of your wishlist because you're starting to run into problems on really new systems Yeah, what kind of systems are these which operating system? For example, I I installed recently a nubuntu 18.4 and I have some inconsistencies because If I want to use easy build there, I have to you to install a python 2 Okay, there are two two problems. Yeah, the I start to have some inconsistencies when I when install python 2 packages and another thing is that Uh, yeah, the the virtual amp this is it the the virtual amp No, I don't know there's something with the its dependencies that is not working completely well in in this new version Because sometimes I got it it looks for uh, python modules in the wrong directories. So okay And do I get a right that python 3 is default in the latest ubuntu? As a system python, okay. Yeah, so that's a very good point. Okay Yeah, I don't know if you noticed yesterday during the talk, but python 3 support is on the top of our wishlist as well For easy 4 so yeah, I saw some mentions of it Hopefully in the coming months, we'll actually tackle that. Yeah Any other questions so that that's great Okay, no more questions. Thank you very much, Jan for taking the time. Okay. Thanks a lot