 Welcome everybody. Good afternoon and welcome to the Biaxel webinar number 70. Today, the speaker of today, Alexander Bomben from the University of Utrecht. Alexander will speak about the new modular version of ADO and it will cover the virtual research environment, integrative modeling and molecular complex. I'm most in this webinar. I'm Alessandra Villa from the Royal Institute of Technology, and with me is Otto Andersson from the Finnish IT Center for Science. So the webinar is recorded, and you have the possibility to ask questions using the Q&A function that you find at the bottom of the Zoom application, depending on which Zoom application you have. Oh, sorry, depending on which operating system you have, you might have this symbol or you might have this symbol. You just click on the symbol and use write down your question. Then you can tell us if you have or not a microphone. So if you want us to read the question for you, just write no microphone. If you want to read to tell the question yourself after the webinar, we will unmute you so you can ask your question, but please tell us that you have a question in the Q&A function. For the future, if you have any question about by Excel activity, you can go to ask by Excel. So something about Alexander. So Alexander Boven studied chemistry at the University of Lausanne in Switzerland. He got his PhD at the University of Houtet in the Netherlands. And after two years of postdoc in Wales and after ATH in Zurich, he joined Utreth University, and he got, he was appointment full professor of computational structural biology in 2009. In 2006 he received a prestigious grant from the Dutch Research Council called Bici. And since September 2019 is scientific director of the by foot center for molecular research is participating in several European project, including by Excel. And the European Open Science Cloud AGI I say project is work as a result in over 250 peer review publication. So now I'm curious to listen about what you will tell us. Okay. Okay, thank you for the introduction I saw. Let me share my screen. Okay. Well, it's my pleasure today to tell you about developments around ad hoc and in particular ad hoc free the new modular version of ad hoc which has been developed under by Excel and still is being developed under by Excel. And our work in the context of a collaboration with the Dutch East Science Center. So I'm going to give you a virtual research environment around ad hoc, and especially ad hoc free in that case. So I'm going to give you a general introduction on the topic. And then I will move into the new modular version of ad hoc ad hoc free we had previous by Excel webinar about that. I'm going to show you where we are going with the virtual research environment that we are building on ad hoc free. So, why ad hoc ad hoc has been developed for over 20 years by now as a tool to study biomolecular interactions, basically the social network of proteins as interactions regulate everything in our lives. The building here is the center of uterates the city where the ad hoc team is based with a lot of interaction taking place at the micro molecular level between people sitting at those nice terraces on the water side. But of course everything that happens here is governed at the microscopic level by interactions between biomolecules. Ad hoc has been aiming at since the early days to be able to build models of those complexes of the underlying assemblies, making use as much as possible of experimental data of experimental knowledge or bioinformatic data to guide the modeling process. So we started from NMR data that have been pointing the binding sites on the surface of proteins and move to biochemical data, cross linking data, exchange, bioinformatics, even prior Yemen small angle is scattering. And haddock since the early days has been also able to model complexes that consist of more than two molecules that's also an important aspect to realize that many assemblies of multiple components. And those components can also be of various types. So protein, nucleic acid small molecule oligosaccharides or haddock can handle all of those. Classically the ad hoc workflow consists of a static path with three main step, an initial step which consists of rigid body energy minimizations where the molecular basically brought together by energy minimization using the data at hand to drive the modeling process. Then we have a flexible refinement stage, which will call it one in ad hoc context where we introduce flexibility at the interface of the molecule to model small conformational changes. And we use to have a final refinement stage in explicit solvent in water to do a final refinement and improve a bit the energetics. So, to all of these stages are associated scoring functions or when we are speaking of modeling complexes we distinguish between the sampling the generation of models, and the scoring which is basically the ranking of those models to identify the best model. Now those functions that we're using for the ranking the scoring functions are very simple. These are, of course, these days you will call these machine learning models but these are simple linear models that were developed 20 years ago, and are still making a good job at doing the ranking. So, you see there are different component of those so that different stages during the protocol we have a slightly different function which we are using. And this will be the classical function that we use at the end of the protocol, which consists of intermolecular energetic components between the molecule, the green energy terms or electrostatic and van der Waals interactions. This is an empirical term that accounts for the price or the bonus that you get by removing water from the interface, and the final term, which we call air for ambiguous interaction restraints. This fried basically the components of the energy that comes from the experimental or bioinformatic predictions that we put into the modeling process. Now this sounds very classical and in these days of AI and machine learning maybe naive but it's still a hard function to beat. We are also of course working on developing better scoring functions and better models and we have developed deep rank and deep rank GNN which is a graph based neural networks or deep learning model to rank complexes. This is not something which is yet integrated into the current version of ad hoc, but that's going to come integrated into ad hoc freedom modular version. Still, even AI has a hard time to beat those those classical simple energy function. One advantage of this is that this is working for variety of complexes so you might have protein protein protein peptide protein small molecule protein nucleic acid interfaces within the large complex that you're modeling and we're using one function. So you might have to work very much to score all interfaces at the same time, while the AI models are usually trained for a very specific class of complexes, meaning that if you have a large assembly consisting of different types of molecule. You might have to combine multiple AI model, if you can train them to score all the different interfaces. So, use of ad hoc has been for the year for web services, which has been operating since 2008 so we have 15 years of providing services to the community. The current version is had a 2.4, which run the static workflow. So users come uploaded their data can tweak the parameters but they cannot really change the workflow which is run. So since the first days of the ad hoc server in 2008, we have have more than 37,000 users that have registered for using the portal, because they are not all active. Some come back after a long period some are come very shortly for a project and we never see them back. And those users are served over half a million docking run since 2008. Now we are able to do all of this and to provide those services because we have access to the European Open Science Club high throughput compute resources grid computing, which are provided to us with the support of EGI. And because of that, we have access actually to over 100 CPU cores distributed around Europe mainly but also Asia and even the US. Now, just a few notes. This is showing you some statistic of the usage of the web service the ad hoc web service since 2020. As you can see, something happened at the beginning of 2020 we all went into lockdown because of the COVID-19 pandemic and people who could not longer do experiments realize that maybe modeling and computing tools were interesting to still do some work. So we had almost a tripling of the number of submission to the server early 2020 and this has been going on quite stable over the year since last two years. We see peak in this distribution. And this seems related to some extent to appearance of new variants of the virus. And the orange bar that you see in the left plot are indicating the fraction of those submissions which corresponds to COVID-19 related research projects. So we have quite a sustained user of the services to model. COVID related complexes. Now this increased usage of the complex is also reflected in a number of unique users per month so a unique user will be a user that submit at least one docking run to the server. And you see that this has increased again 2020 so the COVID-19 effect here. More than doubles and we have a stable usage of the server. So we are not seeing yet in the into statistics the impact of AI alpha fold, which are of course now also providing fantastic tools to predict structural protein protein complexes. But there's clearly still a need for tools like Haddock that have a more classical approach to the problem and support different type of complexes and molecules. This was my general introduction so let's move now into Haddock three. So, haddock version three is a complete rewrite of Haddock to say is where we are basically been breaking the code into modules. And this gives much more flexibility to what we can do in terms of workflows. So this has been the work so that since 2019 and the bike cell to the second round of the bike cell center of excellence we have been developing at three. And this has been the work over the years of Rodrigo Brian Joe and Marco with Rodrigo and Marco still being part of the team in your test. So, what we did basically is to move from the static workflow where you have to go through all those free stages and you can tweak parameters but not the workflow. So basically a modular workflow architecture. So we broke the haddock code into a catalog of independent modules. And this allows us to mix and match those modules to generate different workflows. So here is another workflow which consists of more modules, and this gives much more flexibility to the type of scenarios that you cannot run with other. So this modularization of haddock has also come to a price because we have been stripping down some functionalities for the current haddock free code support anything that can be translated into distance restraints, but at this time the capabilities for trial EM based restraints and cause draining for example, I've not yet been implemented in haddock free. This is something that we intend to reimplement in the future. The modules that are currently available. So first of all we have a topology module where you build basically your system this will build any missing atoms generate the parameters and topologies to do the computations. We have sampling modules so these are modules that will allow you to generate models of your complexes if you start from separate molecules or the rigid body module is the classical haddock. We don't call it zero, but we also integrated here to third party software, which also allow you to do a sampling so live doc, developed by Brian Jimenez and for the whole tourist is integrated into the haddock free module library and G God G doc from Rodrigo is actually a genetic algorithm based docking approach. So we have more flexibility in what we are using in a sampling stage. The refinement modules, we have the semi flexible refinement module which is the classical it one stage of haddock two series energy minimization, which will be the final stage of haddock refinement in the current server, or final refinement with explicit which is, which was a default in haddock to the duration. In terms of refinement we also currently working on an open m m module, which you can connect into your workflow so it's not yet part of the main branch of our three but we hope to be able to release that one also soon. Also scoring modules where you might just want to you have a complex you don't want to generate the complex but you just want to calculate some haddock score possibly do a short minimization or short molecular dynamic system. So we have what we call the em scoring and md scoring, and we build a lot of analysis modules that keeps a lot of flexibility, you know, so in the workflow. So one one of which is this capri evaluation module so if you have a reference structure this will calculate all the capri. You know, you can only do that if you know the reference structure, if you don't have a reference structure what capri evaluation will do is to calculate all those metrics with respect to the best model generated by haddock. And this allows us to generate in the post processing stage of other three, all kind of plots. I'm going to illustrate that in a bit that allows you to visualize the result in the same way that the head of server is actually showing you the results but now from a local So you can do also clustering by using a root mean squared deviation based clustering metrics or clustering by fraction of common contact. Clustering by MSD selection of models so this is kind of a scoring module, or you tell I want to select the top 200 model. I'm going to do clustering and then select the top clusters for further processing. And we are actually also working on a deep rank module which will bring our AI based scoring module into haddock three. The definition of the workflow is quite simple in this model so it's a simple Tamil file, text based ASCII file which describe here what you see a short example so this particular workflow consists of we have to do some counting nine modules so the top way one is the building the topology these are the input data that we provide. And then we have the rigid body module where this default sampling is 1000 in this case we select the best 200 model which we give to the flexible refinement and a final em ref. And then we do clustering metrics do clustering based on the fraction of contact, select the best clusters and evaluate the quality of the cluster to the capri event so that's a very simple workflow. Also compared to the previous version of ad hoc what is also important to note is that the restraints are defined per module in the ad hoc two series the restraints were defined for the entire workflow so you could not change the type of restraints easily between the types of the workflow. Now we define the restraints for each module so this gives you also more flexibility in the type of data and the type of restraints that you might want to include or not a different stage of the work. Open and freely accessible from the GitHub ad hoc free repository. And this is a small timeline history of the development so what you see basically since the early day 2019, the code evolved from the old had a code. There are a lot of things happening here but you see the appearance of all the you see workflow here in the center appearing so this is the core machinery of ad hoc free you see now that some of the modules appearing in this site. Test benchmarking data appearing so this is now we are now 2020 in a well in the middle of by Excel to the point that you see lines for the something happening that commit so you see that there are some major commits to the code which is constantly evolving. And slowly it is converging to what is, I would say a pre release version so we still don't have the official release yet but we hope soon to have an official release but again you. You see that are tagged on the get up side and if you clone the main version you always get the latest version of ad hoc so you see things are not converging you find the other different module. The machinery are on the word for the workflow engine and everything. And you see more the analysis data and some of the over part of the code. And this is where we stand in June 2023. Before to run ad hoc or ad hoc to most of our users are using the web services which we are providing currently had a free basically you have to run it from the command line. So you will call ad hoc you will install ad hoc first and you will call it with a total file which has just shortly described. This is going to generate a result folder and in that folder you will find the different stages of your workflow number based on the on the workflow. In terms of execution modes. So you have a free execution modes currently supported so local, meaning that the ad hoc free will use your local resources to execute the different jobs, the different part of the workflow each model in principle which is generated is a simple is a separate computing load. So more local we just run on you know on your laptop or you could run more local on on the full node of an HPC system you define the number of course, it will limit the number of course to the maximum number of course available in the system. We also have an HPC mode so this is these are these these running modes are basically configured in the total file that you give to ad hoc. So this high performance computing mode where we are currently supporting slurm and talk as batch system. So the compute mode in this case will be HPC, you can define the queue to which you want to submit. If the queue is defined a default buyer will be used. You don't want the jobs that you submit to the queue to be too short because this is increasing the load on the batch system so we are. We can concatenate multiple model into one job sent to the batch system so in this example we're going to calculate five models per job sent to the batch system. And then you can also define the number of concurrent submissions to the queue to your batch system which is in this example is 250. The more that we have implemented and this is news is was not available in the other two series is MPI so parallel execution mode. And in this example, we request 250 cores and of course the allocation of node will have to be done by the batch system so now you are some or you have to start MPI run or you configure your job that you send your batch system to request the number of nodes and the number of corporate nodes too much what you're going to define it so this now allows us to scale had up to larger number of nodes and we did some initial testing this is very much work in progress but we did some initial testing. And here we are doing a sampling of say 10,000 rigid body models and we are refining more than 2000 so those numbers are matching the number of cores so we are blaming all the cores of one node. This experiment was done at the Dutch supercomputer in Amsterdam calls then use. And basically you see the time, basically the workflow time, this is the wall clock time to execute this kind of sampling. If you run onto one node 128 cores and then on about 140 minutes, you go to about 70 minutes if you request to note and you see that then this that's now. This will be the speed up factor so the orange line will be the ideal speed up so we go from one node to 16 node in this case and this is the number of corresponding processors. So ideal will be enough rules of full scaling. If you run the entire workflow. You see that we are reaching about we are above the 50 60% performance on 16 nodes. And where we are losing is that within the workflow we have steps that are selection ranking and these are not distributed step but these are sequential steps and this is slowing down the workflow. There are only the compute intensive step of the workflow like the rigid body sampling or a flexible refinement, you see here that the scanning is much higher. So so the non compute intensive step of the workflow are basically decreasing your scaling still, we get a very nice speed up. So, also to facilitate the use of haddock if you want to run a large number of simulation. Addock 2.0 has developed the addock runner, which is basically a tool which you can find on our GitHub repository so adocking addock runner. It supports addock to four addock to five to five with the same version of addock to four basically same functionalities but this is a Python free port of of addock the server still runs to four. But the functionality exactly the same and we're going to upgrade the server probably later this year or next year to run to five. This also allows you to run addock free workflows. You configure the runner in YAML files that are basically to define the standard scenarios that you want to run so you might say I want to run different scenarios different workflows, and in there you're also going to define the data that you want to run so it does not distribute the the different docking runs that you're going to do in parallel but it's going to execute all of them, and then the distribution will be taking care by by by addock engine itself. But it's really nice for automation and reproducibility of computing. I'm interested to run a large number of docking runs take a look at the addock runner. This is not usable to submit large number of jobs to the server, for example, this is meant to be used with the standalone version of addock. And here are some example of the configuration file so you see a configuration product 2.4 on the left side, where they are two scenarios shown here one will be a true interface so we have the perfect knowledge of which residues are the interface. And here only the parameters that we might want to change compared to the default parameters. And another scenario will be a center of mass this will be an abedition mode of addock, where you define you see that some service parameter the same thing is increasing this case. On the right side you see a scenario for addock free workflow. Again, so this is a true interface scenario where you have general parameters which defined the running mode in this case it's HPC. We define the workflow, the modular defined here so this is a workflow consisting of seven step, basically in this case, and then for each of those steps, you find here parameters that are specific to it. To use the addock runner you have to have a very consistent naming of files. And this is all explained in the documentation online so if you're interested, look it up. Now here is one example workflow. So this is a workflow which would not have been possible to run in a current addock 2.x version of the code. And this is a workflow we are using now to model an antibody antigen complex by the way alpha for this doing very poorly for this type of complexes so they are still need for more classical software. Using as information the knowledge of the hyper viable loops on the antibody and the full surface on the antigen so we have no information on the antigen where things are binding so we target the entire surface. So the workflow in this case consists of 12 stages. Now that you see that there are several capri eval stages which is there for being able to to see the distribution of energy versus RMSD so this is more for analysis purposes if you want to be efficient. You will probably only introduce a capri eval stage at the end of your workflow. So again we built the apology to rigid body docking sampling of 10,000 models, actually sampling is 100,000 but we write to this 10,000 model. And in addock 2 you will make a selection of the top few hundred models and give that to the flexible refiner so here we do something different. So we're doing clustering using faster. The fraction of common contact and this is a fast method to cluster models which allows us to cluster 10,000 models. Then we select all the cluster that have at least a population of four member. And we select the maximum of 20 model per cluster. In this example, this results in a selection of about 200 clusters. So we're going to give 20 model max per cluster some cluster will have a smaller size, and we passed all those clusters to the flexible refinements, and to the final energy minimization refinements. We do a final clustering, and then we scored entire. We assess the entire results using the capri eval module. This is an example of what this does. So, because we put a capri eval module after the g body sampling we had to generate this kind of plots for us directly. So you see here the sampling. This is the doc you score. So the doc you score if it's above point 23 if I'm correct and you have a solution which is of acceptable quality. And one will be perfect quality so the solution that you see here above point seven already very high quality models that are generated. But if you look where they are they are not yet in a perfect region of the ad hoc score. So if you are to select using the old ad hoc to recipe, where we select a few hundred model days I chance that you only pick up model in this regions and you lose those models however do cluster. And by selecting all the clusters that are sample at this stage and passing them to the refinement stage. You see that at the end of the run so this is the final analysis of the results. This cluster which was here is now here, and it's going now as one of the top 10 cluster in this particular example. This is something which would not have been possible in the previous version of ad hoc, but which is not possible in this module of action. So, all of this is, of course, so far come online with some poor generation. And now I'm going to describe you the work that we are doing in the building a virtual research environments to for ad hoc free which will provide basically a graphical interface to the software. And that we wrote and that we are now basically executing together with the inside center was to have different components or so so this virtual research environment will consist of three main component the first one will be the being the ad hoc workflow builder. The idea is that the user can come to this interface with his own data. Select from a module directories all the module supported by ad hoc and in a interactive way build the workflow that he wants she wants to execute and adapt the parameters that are related to the module. This will define the workflow, but we also want to have here is a database to store workflow so we so that we can provide different scenarios up for so user can select from pre existing scenarios. But we also want users in the end to be able to upload their own workflows because they might have devise a workflow which might be interesting for something else. We also have to this database of community workflow for sharing and making the workflow fair or so. Now once you have defined your workflow and you have set all your parameters, this will go into the execution middleware, which will support different execution mode so it could be local, could be HPC connecting to your cluster, could be connecting to the cloud or to the grid. I'm going to come back to that in a bit. And at the end, you will get your results and this will be fed into an analysis storage and sharing infrastructure where basically the idea is that you can interactively analyze your or your runs, possibly change some parameters like clustering, provide access to molecular visualization online, interactive growth and Jupiter and all. So all of this is basically coming together in what we call Everest. And you see the, the GitHub repository down there which is open. So this is very much an evolving project but you can also already look at it and you know download the software and play with it. Wherever the interface with basically present three components on the builder, the bartender what the execution will take place at the management system. So, the workflow builder first. So here is an example of the workflow builder. It is dynamically configured based on Haddock freeze module and definitions and parameters so basically the workflow builder reads the code. So when we add a new module to Haddock, the workflow, this interface will be automatically updated. It's not specific to ad hoc in principle it's reusable for over software as long as you have the same way of reading and importing the parameters. So it makes it very efficient and easy for us if we add parameters if we change module add modules, they will automatically appear in a workflow builder. So you see the catalog of modules with different type of modules. And here is a workflow that has been built you can see in a visual but if you switch to the text view then you will see the thermal file, the simple ascii file. And it's basically a drag and drop system. And when you click on one of the module on the right side there's a window that appears with all the parameters that you can configure. There's also different user level so you can use the workflow builder at the easy level so that you don't you're not exposed to too many parameters but you can go also at the advanced level where you see all the possible parameters that you might change. And this is usually quite a lot. Here is a small example of building such a workflow so again you see a list of modules you can select from here is a workflow that has been built. Switching to text, and you see again for each modules, you can change different parameters. And at the end you can download basically the entire data. You will download the thermal file that allows you to execute the workflow on your system. What we have also been doing is to provide different tools basically to use this workflow builder so one of it is an integration into the Galaxy system so if you go to the GitHub repository of eBress you will also find this code. Well now in the Galaxy system you can basically build Hadock workflows. And we also have an integration in JupyterLab so that with Jupyter notebooks basically you can build Hadock workflows. Now the bartender which is the core of Hadock this is what is going basically it's a back end that's going to schedule the jobs on virus infrastructure. And it will also provide the user management and with social logins and also single sign on capabilities. The idea for the bartender but also for the workflow is that you can also install and configure it on your system so you can run this interface on your own system so that's not us providing all the infrastructure but this is customizable to everyone's infrastructure. We hope in the future that we will have an interface running on our servers directly in Utrecht but we'll have to see about capacity and running mode. Basically the bartender is running as a RESTful application where you configure it so it could be your HPC cluster and it has a number of standard API which will be queried by the interface by the bartender. So this needs to be configured on the system of your choice. So this is an overview of what the bartender is supposed to do and look like. So the user upload has defined a workflow it's going to upload and select the destination the destination will depend of course on what has been configured on the back ends of the bartender. And currently we have different modes that are implemented supported but these have to be configured so you see again like a high throughput mode slurm. We are currently working also on the DRAC so DRAC is a job management system for high throughput computing which is used on by EGI. This is what is used currently by the Hadock 2.4 web portal to distribute job loads over this 100,000 CPU cores that we have access to. So of course here there will be configuration that has been done to be able to connect to the system but in principle the machinery is there. And then you can run in memory on your own system so you can even install the bartender in principle on your own laptop. And there's a monitoring basically layer the bartender that is basically monitoring if the jobs are completed or not and if they are completed it will basically retrieve the data and present the results to the user. And the last part is the basically the management and analysis platform. So this will provide the data management analysis and visualization tools. So this builds actually upon plots and analysis which is performed automatically by Hadock 3 so even when you run a local version of Hadock 3 without the Everest environments by default this kind of plots will be generated. And with a simple Python command you can launch a local server and inspect those results for a web browser. So you see here what you see here is a we present the top 10 clusters. This is what Hadock 2.4 server is showing you as well plus Heidi size different metrics statistics. So you see here RMSD so if you have provided a reference structure this will be with respect to the reference if you are provide no reference structure this will be with respect to the best model generated by Hadock. So you get all those statistics energetics here and then you can view online in your browser, the different models, or save them. You can also have these plots. These are the same kind of plots that the server is providing you but not they are provided by Hadock 3 itself. So you don't see we without the server you can still analyze your results in the same way that you will do when using the Hadock 2.4 web server. So if you have an interactive plot if you hover on the points, it will tell you which model it is what are its what its core RMSD and all of that. So I think that's a very useful addition to add in Hadock 3 which makes it look and feel much more like the server in Hadock 2.4. There are such plots so you can click on the clusters to make them visible or not. In this case we're plotting the RMSD of the interface versus the Hadock score and this is with respect in this example to a normal reference structure. And here you see a pair cluster the distribution of scores of the Hadock score. So how will this all look like. So this will be a web application, which will be the bartended Hadock. So this web application, you might run it on your own system, or you might connect to the web application that we are going to run from our servers in uterates. So this will manage the login into the system. So we need people will have to register to use these tools. So this is the workflow builder basically to configure the workflow and the parameters that we want to run and the builder, we in the context of the bartender Hadock 3 will submit the job to the bartender, which will run them calling Hadock either locally on HPC system on the cloud. And it will basically the web application will basically monitor then the state of the job actually the bartender is doing that but the web application will communicate with the bartender to monitor the state of the job and when it's finished it will provide the results of the job. So all of this is built on those three components, the builder, the bartender, and then the web application which will provide you the interface to the results as well. So all of this is available, you know, Everest, GitHub repository. If you know a bit of French you will understand what Everest is, and we'll see that this is a very nice combination with Hadock, of course, see Hadock in the state of Everest I would say. So we see the workflow builder, the bartender is here, you see the Hadock 3 Jupyter Lab implementation and some of the tools that are there. So if you look at this if you're interested, remember this is an evolving project and we still have quite some work to do. So to wrap up things in conclusion. So we are currently finalizing the first production release of Hadock 3. So for now we still have several data releases but we see that the community is picking up people are using Hadock 3 already, even contributing to it so it's nice. It's really a community effort. So we invite people to contribute. We have also in the documentation instruction how to contribute and how to build modules. We have now integrated analysis to inside Hadock 3. And these are now leveraged by BRE by Everest to present the result page but this is also available from the local installation of Hadock 3. Very much HTC I throughput compute but also HPC oriented because by Excel is operating in the context of Euro HPC and where we have to improve usability and scalability and performance of our code on the next generation of exact scale computers. Very much related to all the Hadock 3 work in the context of by Excel is the virtual research environments work for interactive modeling the Everest project which is running collaboration with the Dutch Science Center. So this will provide the user friendly interface and integrated back end to build execute and analyze Hadock 3 workflows. It will be possible to install it locally, but also use our own interface to that one in the future. While currently for Hadock 2 we are running the interface and this is not a code that we are distributing because it's way too complex for that. I hope to also have a provide easy deployments with Docker compose off site. And the technology behind Everest actually is a generic and can be reused by our project so it's not tied to Hadock. With that I want to thank the people who have been contributing to the work so you see some of our current group members here and some of the former members who have contributed to all the Hadock developments. Especially big thing to Rodrigo who is Marco, Joao and Brian who are the architects of Hadock 3. Rodrigo is also the one who developed Hadock Runner. And he's the one who is making sure that our web infrastructure is operating so that you as users can make use of it. And we also provide more support. Victor joined the team recently is the one who is currently working on the OpenMM module, which was a project from a master student in the past. Xiaotong is a master student and a PhD student, excuse me Xiaotong. And she's the one who is working on implementing or deep rank AI scoring module into Hadock 3. And in the context of Biaxcel, we hope soon to be hiring two postdocs to contribute to further development so if you are interested do contact me and keep your eyes open when those positions will be officially announced. So all of these over the years have been supported of course by a funding from national projects from European project with Biaxcel being a central role in all of our Hadock 3 code development. And I should not forget of course to thank also the eScience Center team. We're doing a fantastic work in the Everest project and building the virtual research environments of Stefan, Peter and Sarah. We're contributing a lot to Everest but also actually to the Hadock 3 development itself. With that I'm finished, and I will be happy to answer any question you might have. Thank you very much. Thank you very much, Alexander. It was great. So maybe there are no Q&A, no question type, but maybe I just activate the chat so people can just raise the, sorry, activate the raise center so they can just raise their end so they can also ask questions in this way if I can. Let me see. Otherwise just use the Q&A and then right there your question and then we will read. Okay. Now you can raise them if you have a question. I can see it. Oh, we have a question. Okay, from Andrea. Wait, I try to unmute Andrea. So Andrea, now you can ask your question directly if you want. Andrea is not, now he can speak, but he doesn't speak. Okay, we can read the question. I can read the question. First of all, amazing work with the new Hadock 3. I have been using Hadock since the version 1.3 and this represents a breaking throw in the protein protein docking in terms of high flexibility. Do you think to add something based on bioinformatic data to drive docking when no experiment data are available in this new framework? I mean, I mean, basically, do you think to embed C port and whiskey or similar or similar in Hadock 3? So this is something of course C port has been there also for quite some time as a web service as well and we have been revisiting it. So we have now a standalone version of C port. So I think this, this will be a logical thing to do. What we have also been working on and this was a master project from a visiting students from Italy, Philip was been implementing the co evolution module actually. So this is something that will also be interesting to have. So we can build a module so we'll have to see from a workflow perspective because the module itself will generate data not per se model so it means we might have to branch. So at this time we can we don't have yet the machinery to branch the workflow so it's a linear workflow but I think these kind of things will be great to have directly as modules. And we of course welcome contributions from third parties. Okay, so if someone has a question can just type in the Q&A or just raise the end, and I will approve you to ask to ask your question. I think it's good to take the chance. In the meantime, people are thinking. I can see things I can just announce the following webinar. So then we are done in the meantime, people may think about some questions that they have. And they can. Okay, so that was, let me just. Okay, so then the next webinar, we will be next week. It will be of June and we'll be about Gromax PMX for an accurate estimation on the free energy difference is from from Sudan, Sudan, from the Max Planck Institute in Göttingen, and the registration is open. Yeah, Andrea went back for from with another question. This is asking is the scoring function still a holy grail. As you said once is MLE AI is far away from help us in this terrible dusk. I think there is still a lot to be done. Yes. So if we look at a deep rank and deep rank is being used as as a reference if there are several work that are being published now where you see that deep rank is actually one of the better one at this time for protein protein complexes. But it's, it still has a hard time in our hands to beat the simple Hadox core. I think some of the advantages for for this kind of AI models is that they may, they might be less sensitive when you deal with models that are coming from different software. So our scoring function will of course be very sensitive to where the model comes from. So if you use another docking software like rigid body docking software Z dot plus pro, which typically have more clashes at the end, or scoring function will probably do quite bad, while the one might be more work better. I see a lot of things happening also in a small molecule world for with AI so there there's a lot of scoring functions coming up which which works quite nicely. I think one of the limiting factor also in all of these are is the availability of data. So if you want to want to train models you need good data. So I haven't seen much yet happening for DNA for nucleic acids RNA. Maybe we are limited by the number of data but but it's coming there as well so it will come. The issue is that if you are building systems that consist of multiple types of molecule. There's no yet AI function that can score all different types of molecule at the same time. So you will have to score based on interface and then find a way of combining all those scores, and that might not be trivial. While if you use more physics based scoring then this applies in principle to all interfaces at the same time which was what we are doing in head up. But of course you know if AI comes with a very good scoring function and you see for example alpha folder can be used as kind of a scoring function it's a bit expensive it depends on the model that you have to score but it's doable. And it's doing quite a good job. So we have to keep our eyes open and and move with all the development that are taking place now and the field is changing extremely fast. So Andrea was sorry that he cannot speak. So that is, but it's not a problem. It was typing good. So, yeah, so I thank you everybody if there is no question I thank you a lot Alexander was a great presentation, and I thank you all the attendees to be here and see you next time. So I will close this webinar section now. Yeah, bye bye. Thank you bye.