Let's continue with the next part of the tutorial, which is the basic usage. So for this part, it's important that you make sure that the pre-installed software stack that we have and the container image is available. So for this, we need to run the module use command that is shown in the slide here. This is mentioned throughout the tutorial a couple of times, but we can already do this here. So we run module use slash easy build modules. All. We now run module avail. You should see a bunch of modules already pre-installed for us. That will come in handy. We have stuff like CMake already installed. We have a GCC, recent version 903 installed. We have a Perl installation and a Python installation that was performed by easy build and a whole bunch of other tools and libraries that we have, including a full FOSS tool chain the latest version 2028. So make sure you run this module use command and that you see a bunch of software pop up in module avail, which is important for the next part of the tutorial. So this part will cover the basic usage of easy builds. This part here, it's a fairly long part. And it does include a couple of exercises at the end, which you should try and solve yourself. So the basic usage of easy build or the workflow of easy build is use the EB command as I already showed, and you specify the name of one or more easy config files. And often you also enable the robot option to enable dependency resolution and we'll get to that in a bit. When you do this easy build, we'll install the software and make sure that all the required dependencies are installed first. And here it says, maybe you want to inspect the installation procedure before actually running it and we'll show you how to do that in this part. So first of all, specifying easy config files. How do we do that? Well, we give the name or the location of easy config files to the EB command. That's the most common way of telling easy builds to install a particular software package. There's alternative methods like the dash dash software name option, but these are not really used too much and they are not that easy to work with. So usually people specify the name or the location of easy config files. There's a couple of ways to do this. It can be a relative or an absolute part to a config file, so the full location. You can just specify the name of an easy config file or you can specify the name or at least the part to a directory that has easy config files in it. So these are subtle differences. We have an example here that hopefully clarifies it a little bit. So this is the type of directory we have. We have in our current directory, a file named example one, a file named example two. So both of these are easy config files. We have a directory, some depths which has two easy config files in them. So usually easy config files have a dot EB extension, but that's not strictly required. It's just smart to do that because then you can easily tell they are easy config files. It has a list of the XT file which we will ignore in this case and a subdirectory more depths with another easy config file. If we now run this command with easy build, this has a couple of arguments. Here we give the name of an easy config file that's included in the easy build installation. So easy build would first check in the current directory, is this file there? If it's not there, it will go and search in the robot search path for this file and it should find it there since it's part of the easy build installation. The next one, it will do it, again, a check in the current directory. It will find this file and then it will be happy. It will pick it up and parse it as an easy config file. Same for this one, except here we are using an absolute path to the file which in this case works as well since the assumption here is that all these files are in the home directory. And then the fourth argument is a directory, some depths which has easy config files in them. This will make easy build scan the directory recursively and pick up all the files that have a .ed extension in them. So this has to be done with some care if this is a top level directory with thousands of directories in there, easy build will scan all of them. So this is something to do with some care, I would say, but if you know it's just a directory with directly easy config files in them, it's okay to do this. So this explains this in detail. The names of easy config files do not matter as long as you specify them to the EB command itself. So the example one here, for example, this works fine if this is an easy config file because it's specified directly to the EB command. So easy build will find this file and use it as an easy config file. Usually easy config files have a .ed extension but that's not strictly required as long as you're specifying them to the EB command. Whenever easy build needs to find easy config files that are not directly specified, however, the naming of the easy config files is very important. So easy build will not open any file it runs into, it will do the searching for easy config files on the name base. So whenever it needs an easy config file to resolve a dependency, it will look for a file with a very specific name. So that's where the naming is important. The naming of easy config files follows this scheme. So it has name dash software name, I should say dash software version. The tool chain label, which is basically the name of the tool chain dash, the tool chain version. And then a version suffix, which is an additional label you can give to an easy config file followed by the .ed extension. As you will see in the coming parts of the tutorial, all easy config files that we will use have this structure to them. And we recommend also to use the same naming scheme for the local easy config files you create yourself. So one of the first things you will need to do when you want to install a particular software package using easy build is to search for an easy config file that matches your requirements. For this, you can use EB dash dash search or just EB dash capital S for short. There's a subtle difference between these two. One of them will give the full location to the easy config files that match the search pattern. Or the other one gives a more condensed output. So when searching for easy config files, easy build will consider all the directories in the robot search bot. So remember from our show config output, the robot search bot is this list of parts which is in this case, only one part. So in this case, dash dash search will only consider the dislocation when looking for easy config files. When we do this, for example, for TensorFlow 2.2.0 using dash dash search, we get two hits, one with the FOS 2019 B toolchain another one with the FOS CUDA toolchain. So this is a GPU Able installation of TensorFlow. When we do the same thing with dash capital S, then we get the same easy config files, of course, but the output is a little bit different. So here it sees there's a common prefix to these easy config files where it sort of defines a variable for the prefix and then only gives the name of the easy config file. So it's a little bit easier on the eyes or to copy paste. Important here, the search is case insensitive. So even though I did TensorFlow all in lower case, it's able to find easy config files that have the capital T and the capital F in the TensorFlow software name. So searching is case insensitive, but whenever we use these easy config files, the casing is important. So an easy book checks for files or when the robot checks for easy config files or searches for easy config files, casing of the names of the final names is important. We can also give a particular pattern rather than just a regular string. So for example, if you want to look for easy config files for open foam, where the version starts with the digits and which uses the FOS 2019 B tool chain, we can use this query.  We have to wrap this in single quotes to avoid that bash goes and play with this. So when we run this, we get two easy config files for open foam version six and version seven. Whenever you do a search with EasyBuild, you will see a line or at least a sufficiently recent version of EasyBuild. You will see a line like this pop up. So EasyBuild has a search index that is automatically created for the easy config files included with EasyBuild which speeds up the search a bit. So this directory now holds almost 10,000 easy config files. And when this directory is on a shared file system, it may make the search a bit slow. So that's why we added a search index as well. And you can create your own search index for additional locations where you have easy config files located. There's more details on this in the EasyBuild documentation behind this link for the search index. Then when we know the name of the easy config file we want to install, we may want to take a closer look at it first before letting EasyBuild install it. So for this, we can use the show EC, which is short for easy config option. So EB show EC and then the name of one or more easy config files if you want to repipe this through less. So this shows us the contents of the easy config file. So this is an easy config file for Bzip 106 which is not a surprise based on the name of the easy config file. It shows the metadata, the homepage and the description. It shows the tool chain. In this case, the system tool chain that would be used where it would download the sources from what the source file would be named like. And here it's using a constant that we will use later as well. This even includes a patch file for adding a package config file to the installation. It gives the build options for the build command and so on. So all of these details we will go through when we get to writing easy config files ourselves. But the show EC option is handy for checking the contents of an easy config file before you start playing with it. Maybe you want to double check it's actually the Bzip you're after and not just any other software package named Bzip. Another thing you may want to do before installing software is checking the dependencies. So this is where it's important that you have run module use, easy build modules all to pick up on the installed software we have in the container image. So one way to check for dependencies is using a dry run, which is eb dash dash dry run. Or again, we have a shorthand for this which is eb minus capital D. So again, here you give easy build the name of an easy config file and use minus capital D when running this. When you do this on this easy config file which is one for SAM tools, 1.10 installed with the GCC 9.3 compiler tool chain. When we run this, we quickly get an answer back. Easy build will give us a long list of dependencies including the tool chain itself and all of its dependencies. And everything that's already installed will be marked with X here in the output. In this case, it's good news since all of these are X, the tool chain itself as we have seen the module for the tool chain is already installed. So this is marked as X. You have a dependency end curses here which is also marked as X since it's already installed. But SAM tools itself is not installed yet so this is still blank here. So in this case, we know that all the dependencies that are required to install SAM tools are already in place in this environment. So this is a long list of dependencies which is a bit hard to stare at. We can also ask Easy Build to only tell us about missing dependencies. So let's let me do this on the SAM tools one. So dash, dash missing or dash capital M. In this case, as we've seen only SAM tools itself is missing and everything else is already installed. So this is a bit more easy to look at maybe. The example here does the same thing for H5Py. So here we're using an easy config file for H5Py version 2.10.0. In this case with the FOSS 2028 tool chain and with Python 3.8.2. If we run this, Easy Build will tell us that we have two installations missing, of course H5Py itself and also the package config tool or rather the Python wrappers for the package config tool which are required as a build dependency for installing H5Py. So we're still two modules missing to have this H5Py installation in place. Next to checking dependencies, maybe we also want to get a closer look or take a closer look at how Easy Build will exactly perform installation. So I mean, we want to do this quickly not just waiting for minutes or maybe even hours for the installation to run and then check afterwards what it did. So for this, there's a separate option which we call extended dry run. So it's a bit of a weird name maybe but it was for lack of a better one that we could come up with. There is a shorthand as well, eb-x. This will basically run through the whole installation and just produce outputs without actually doing anything at all. So this will run in seconds and this will give a quick report on what Easy Build would do if it installs this software. If you do this with the boost easy config file we show here. So we run again eb command, the name of the easy config file and we add dash x to tell it to do the extended dry run. Let me pipe this through less because this will generate quite a bit of output and we can scroll through this a bit. So here it tells us which easy config file it's picking up. So the robot search mechanism has found this easy config file as we specified it. It knows the full name. It tells you here that the installation procedure reports on may diverge a little bit and this is covered in the text here in the tutorial as well. It tells us which easy block will be used where the easy block is located in case you want to check the code which module it would install which URLs it will consider for downloading the sources. And in this case, it doesn't have the source yet because it says it will download this source file to this location. If it would have found the source file it would have told us source file is found at this location on the file system. So in this case, it still needs to be downloaded. There are no patch files in this particular installation for the checksum. It will use this checksum to verify verify that the source file is correct. It will extract the source file. It will prepare the built environment by loading the tool chain module and loading the modules for the dependencies. And this should result in a list of loaded modules that looks like this. So remember it does all of this without actually doing it. So it's quite smart to figure out all these details. And it shows us how the built environment will be defined which corresponds to defining a bunch of environment variables which is a long list including CXX, CXX flags and a couple of familiar ones and maybe some additional ones which are less familiar. It will show us how to run the configure step, how to run the build step which is a whole bunch of outputs because it's passing link flags here corresponding to each of the dependencies. It will tell us about testing. In this case, there is no dedicated testing step it seems the installation itself looks like it skipped here but that's actually because the boost easy block doesn't output anything in dry run mode about how it will do the actual installation. That's maybe something to fix. And it will perform a sanity check by looking for these particular files and this directory which are expected to be there in the installation before declaring success. When it does see all of this it will generate a module file using these parts that it will consider for updating environment variables and it also gives an idea of how the module file will look like. So it will have load statements for the tool chain and the dependencies, a bunch of prepent part statements in the module file. A couple of additional ones for setting environment variables and then we'll wrap up with cleaning up and the same note again that this installation procedure may diverge a little bit from what will actually happen depending on what easy build runs into when doing the actual installation. Well, as you can tell, we got this output in a matter of seconds and it takes us longer to scroll through the output than it took to generate it. So this is a very good way to get a quick idea of what easy build would do giving the easy conflict file that we passed it. And again, here this note says depending on files or environment variables or output of commands that are actually run during an actual installation, easy build may take a different part in the easy block. So that's certainly something to take into account. It's not guaranteed to be 100% correct the output you get here, but it does give a good idea. Then let's try to actually install software rather than just looking at what would happen. So here, remember the SamTools example that we had before there was only one dependency missing which is what installation missing which is SamTools itself. So when we run the EB command and only give the easy conflict file name it easily goes ahead and installs SamTools for us. This may take I think a minute or two because SamTools does involve quite a bit of source files that need to be compiled. So it will go ahead and do this for us. Once it completes the installation procedure you should see output like this. So one line for each of the steps that easy build perform during the installation and it should end with a completed message the 11 seconds here is a bit optimistic. In the AWS environment we have a lot less resources but it should finish in about a minute or two. And that's really all there is to it. You give EB the name of the easy conflict file you hit enter and then everything happens automatically for you. So in this case it's completely installation. Remember we had easy build configured to install stuff in dollar easy build slash home. If you look at modules all you should see a module for SamTools and this particular version and in the software directory we'll also have a SamTools directory there for this particular version of SamTools which has the actual installation. So is it that easy? Always well mostly depends a bit on the context. If you have a bunch of dependencies missing like for example for this bow tie software package with dash M we can check which dependencies are missing we have two missing here. If we now ask easy build to install bow tie for us like we had before this will actually fail after easy build downloads the sources which will hopefully not fail in this case. The installation will fail because the TBV dependency is still missing. So this one is not there. And here of course it's failing on the source files. That's not fun. So there's a problem with source for source, source, or which I guess is the issue we're hitting here. Let me see if I can locate alternative location for the sources. I can pull them in here and name the source file. Is this zippable? So usually easy build doesn't automatic download. And of course this is hosted on source forage. Maybe this one gives us an alternative link that you can try. This is maybe not a bad example. If you run into issues like this, that was a bit quick. Yeah, this is an HTML document. I don't know what we need. Okay, so I'll divert to a different example since the sources cannot be downloaded currently. Let me see if I can find another example. So what was I trying to show here? There was a dependency missing. So if we just run EB, but the easy config file name, the installation should fail after fetching the sources because the TBB dependency is missing. So you'll see output like this. Missing modules for dependencies, which is copy pasted here, TBB is missing. In this case, the fix is quite simple. We have to enable the dependency resolution by using the dash dash robot option or the dash R option for short. So in this case, easy build will first handle the bow tie installation. So it will build and install the TBB installation first and then it will get to installing bow tie itself on top of that since all the dependencies are in place. So remember when you hit an issue like this where it says missing modules for dependencies, you probably just forgot to enable the robot mode. And if it takes a while for installing a software package and you're only getting very high level output like configuring and building, you may be wondering what is actually going on in the background. This is actually the case for bow tie if the download works at least. You will see it's sitting there and the building step for quite a while. And you may wonder what's actually going on. So for this, we have the trace mode and I can maybe show this for the TBB example which I think is not hosted on SwarchForce. SwarchForce like this. So let me run this with trace mode enabled just to give you a feeling of what it does. So now we're getting a whole lot more output when running a particular command. It's not only giving us building but it's also giving us details about which command is actually running, in which directory it is running when it was started and it even gives us a temporary log file to check the output of this particular command. So we can follow on what it is doing. And eventually it completes and it gives us a good idea of what the output or what the sanity check was checking for. So this is the trace output. It gives us more details about what's actually going on in the background while EasyBuild is installing the software. It only gives us information about the build commands but also the sanity check gives some more details. In the case of bow tie, it will tell us that we're looking for a bow tie binary, a bow tie build binary, an inspect binary and a couple of non-empty directories as well. So once we have installed software, if you have the bow tie sources, you will have installed three packages up until now, SAM tools, TBB and bow tie tool itself. So how do we now use this software? So remember we have the software in our home directory, Home EasyBuild. We have the modules subdirectory here and the software subdirectory. So the actual software is located here. So we have a SAM tools, we have EasyBuild itself from the bootstrap before and the TBB installation. How do we now actually use this software? And I guess I was also using bow tie as an example here. So this again goes back to show config so we can remember where software is being installed. Which is basically what I'm doing here, checking with the less where stuff goes. If we check in the modules directory, we will see separate subdirectories for bioinformatics software, for development tools, for libraries. But all the modules we generate are also located in the slash all subdirectory. To actually use the software, we need to make sure that the modules tool is aware of where the software is installed. So if we now check for module avail SAM tools, for example, we have this already in our module part. So we ran the modules tool, module use commands before because this Home EasyBuild modules all is already in our module part. If this is not the case for you, you should run module use Home EasyBuild modules all. Since this is the location where we are installing module files, the modules tool needs to be aware of this location. With that in place, we can check for both SAM tools and TBB in this case. So we see both these modules installed. And if we have the bow tie sources, we should have bow tie as well. And maybe I think this one was installed after the configuration part, which is a quick installation with the system tool chain, which I haven't done here in the demo. So to actually use the installation, we have to load the corresponding module. Let me do it here for SAM tools. So we do module load in the name of the SAM tools module. And now I have to take a quick peek what's actually there in the installation so we can check which commands provided by bow tie, Home EasyBuild software, ah, SAM tools, not bow tie, 1.10. And here in the bin directory, so for example, we have the SAM tools commands, which may have a dash dash version option like this. So because we have loaded the SAM tools module, this one, we now have the SAM tools command also available. If we check with which, you can tell that the shell is able to find the SAM tools command in our home directory, Home EasyBuild software, SAM tools, version and then bin SAM tools. That's the location of the actual binary. If we unload the SAM tools module and then try again, we have lost the SAM tools command because it's no longer an actively loaded module. So the example here shows this for bow tie where we don't have the bow tie command until we load the bow tie module. And from there on, we do have the bow tie command available and we can run dash dash version on it. When you have loaded a bunch of modules, so module list currently shows still the modules loaded for the tool chain and the dependencies of SAM tools. If you want to reset start over, you can unload modules like I did for SAM tools or when you just want to start from a clean slate, you can run module purge, which will unload everything you've loaded before and starts from a clean slate. So this is one of the reasons we didn't want to have EasyBuild itself as a module because then we have to make sure we reload the EasyBuild module after running module purge. Stacking of software, this is a small section that basically says you can build additional software on top of other software, which is exactly what we're doing here actually because, so let me load the SAM tools module again. If we check where SAM tools is, we can see it's in our home directory, which is where we have self installed this. But if we, for example, check where GCC is located, which is the tool chain compiler we are using, we can see it's in slash EasyBuild software. So this is part of the pre-installed software stack in the container environment. And this may be a location where we don't have right access to. So even though this is not software reinstalled ourselves, we can still leverage it for doing our own installations. So you can easily stack software on top of each other. You don't have to reinstall everything in order to install SAM tools or any other tool you're interested in. As long as you have a compiler tool chain and maybe a bunch of dependencies like Python and Perl already pre-installed for you, you can just leverage those and build what is missing based on what you need. So here there are a couple of hands-on exercises that work you through the workflow. And most of them are fairly simple. So hopefully you can spend, let's say about 10 minutes to walk through them before we continue with the next section, which is a troubleshooting part. So please take a look at the exercises here and try to work them out yourself before we continue. Email if there are any additional questions. People who are helping out can raise them to me. I can quickly answer them before we continue. So somebody's passing me a question. You set the build environment by loading module files. Are you using the same module outside of EasyBuild to let users employ the software? So when EasyBuild prepares the build environment when it's installing a particular software package, for example, SAM Tools, it will load both the compiler tool chain, the module for the compiler tool chain and the modules for all of the dependencies. Then it will go ahead and do the installation and in the generated module file for the installation, it will again load the compiler tool chain and the dependencies, the runtime dependencies. Also during the sanity check, before EasyBuild runs the sanity check, which often involves running small commands like dash dash help or dash dash user. EasyBuild will actually load the module just like a user would and then run the commands just like a user would. So that's a way, an easy way to make sure that the software seems to be functional. We usually don't run extensive tests in the sanity check, but some quick commands that give some idea of how well the installation is working. Are being run. So I hope that clarifies that question a little bit. I don't want to stall too long here, waiting for exercises. So I hope everything is going well in terms of working on exercises. Let's take a quick look at what we have here. So the first exercise is to make installed software available, which we have covered with in our case, the SAM Tools example. So here of course, make sure that you're using the pre-installed software stack so you don't have to reinstall everything from scratch. Run this module use command to make sure you're picking up the modules that are installed in slash easy build to search for easy config files. Let me re-wipe my environment here and run this side by side. So when searching for easy config files, we can use eb dash dash search. And in this case, we want grow max 219.4. We can use the long version dash dash search or the corresponding shorthand dash capital S which gives us a more condensed output. So this is one easy config file that is part of the easy build installation for grow max 219.4. Then to check for dependencies, here we are asked which dependencies are missing to install a particular version of the Petsy software package when using the 2008, 2020 version of the FOSS toolchain. So first of all here, we'll have to look for an easy config file that matches this. So we'll do Petsy 312.4. The toolchain should be in there as well. So we'll do dot star. The name of the toolchain and the version of the toolchain. And we'll wrap this in single quotes to avoid that bash starts playing around with the dot star here. If we do this, we get exactly one hit. So we have an easy config file for Petsy 312.4 with this toolchain and also for the particular version of Python. Now the question is here, which dependencies are missing? So either we use eb minus capital D or dash dash dry run, which is the long version for this. But this would give us an overview of all dependencies including the toolchain and the dependencies of dependencies and so on. So this will be quite a bit of output. Or we can just run dash dash missing or minus capital M for short to only get a list of the missing dependencies. When we do this for this Petsy easy config file, we get an answer back that seven out of 75 modules are still missing. A number of important dependencies for Petsy like metis and boost, sweet sparse, hyper are not installed yet. So all of these six have to be installed first before easy build can continue and install Petsy.  Here we are asked to figure out the actual command that easy build will run to install the GNU scientific library using this easy config file. So here we get the easy config file, we don't have to search for it. And to figure out how easy build would install something we use the extended dry run mode or just dash dash lowercase x for short and pipe this through less is a good idea since it generates a lot of output. When we do this and we scroll down a little bit or we look for install deeper down in the output we see during the installation step easy build will first create the installation directory and remove it if it's already there. And during the actual installation step it will just run make install from what looks like the built directory. So that's basically answering the first part of the question here. And the second part it asks which binaries will easy build check for to send the check the installation. For this we have to scroll down a little bit further to the sanity check part, which is here. So the binaries that easy build will check for are these three GSL config GSL histogram and GSL rendist. So easy build to expect all three of these binaries to be available in the installation. If one of these is missing easy build will consider the installation to have failed and it will stop the installation it will not generate a module file for it. If everything that is specified here is in place then easy build assumes the installation went as was expected. And then here to actually install software so here we are asked to install H5 Pi and all of the missing dependencies on top of Python 3.8 and to do this in slash temp user easy build while leveraging the already installed software from slash easy build. So start with the last part leveraging the software that's already installed in slash easy build that just having the modules visible so which means they pop up in module avail is good enough we don't have to do anything special for that to install H5 Pi we first have to locate an easy config file for it it says H5 Pi for Python 3.8 so let's make sure our easy config file includes this Python version this is the name of the easy config file we will need we will pass this to the EB command we need to make sure all missing dependencies are also installed so let's check on that first with dash dash missing we can check which dependencies are still missing in this case it's package config and of course H5 Pi itself so hopefully that doesn't take too long and hopefully the download doesn't fail on us to make sure it installs package config before it tries installing H5 Pi we use the dash dash robot or just dash R for short to enable dependency resolution so here it goes and installs package config first so that's quick this installation completed and then it continues with H5 Pi itself now this is taking a bit long so let me cancel it ctrl C because this build step I want to figure out what it's actually doing there so let me also enable trace mode with dash dash trace if we enable trace mode we'll get some more information about what's actually going on here we see it preparing the build environment by loading models for build dependencies and runtime dependencies and the toolchain itself and then during the build step so this is where it seems to be hanging hopefully it's doing some useful work here by running this command Python setup by configure with MPI support enabled passing the location of the HZF5 library and then afterwards after setup by configure it's also running Python setup by build so this seems to take a while let's let it work on that while we look at the last exercise so here once we get a working H5py installation we are asked to make sure it works by running this small Python program which uses H5py to create an empty HZF5 file and we're then asked to check the result of running that Python script using the H5 stopped command so for this of course we need to wait until the H5py installation finishes first let's complete this exercise as well before we continue to the next part which is troubleshooting there are any questions please raise them to me if they are worth answering during the tutorial okay this H5py installation completed did I actually do it I was supposed to I was supposed to install it in slash temp slash user but let me ignore that for now since it takes a couple of minutes to get this installed in this case we should have the module available for loading already since it was again installed in our home directory so we can go ahead and load this module assuming we don't have anything else loaded that's fine the module load H5py and then we are asked to run this small Python script so let me copy it and create a file here let me use the AWS file browser for this so here I use the plus here to create a new file copy pasted the contents of the file and when I do control s it lets me save the file I can give it a name and a location I'll put it in the directory that we mounted in the container image and I'll name it test H5py and save it of course you can also directly create the file here in the terminal using your favorite editor whether it's nano, emacs or vim so the file should be here now since I have loaded the H5py module I can assume H5py is available so I should be able to run this Python script let me check the Python version 3A2 which corresponds to the one for which H5py was installed so I can run the Python script using Python and the name of the Python script that should create an empty.htf file for me and then here I am asked to run the H5stop command on that to check it first make sure I have this available this looks okay the version looks a bit weird but it's probably fine I don't know how H5py actually the version comes from HDF5 itself not from H5py so that's why the version is different check which HDF5 module we have loaded it should say the same version as H5starter gives us which is 106 indeed so let's run H5stop on empty.htf5 and this gives us a whole bunch of useful output about this empty.htf5 file so this seems to be working indeed we have created a correct HDF5 empty file using this small Python script leveraging our H5py installation that concludes this part of the exercises there's a question that's being raised to me why use the trace option and not verbose a guess with verbose you mean logging the or sending the output the sorry log output to the terminal so there's a log to standard out option for that let me show you why not so here we use dash-trace which makes it fairly easy to follow what EasyBuild is doing in particularly doing the build step for H5py if we redo this so we do rebuild to reinstall H5py even though it's already there and we use log to standard out to get all the details on what EasyBuild is doing this is why we typically don't use this it generates a lot of output a lot of details which is probably not what you're after so this will overflow you with information which may be useful to look at after the installation complete but not while it's running you can see there's a whole bunch of things going on here we're getting warnings from Python we're getting output from the build command and this is just impossible to tell if we compare this with the trace output it's a lot cleaner and manageable and intended for humans so it does scroll a little bit but when it pauses for a while we can tell what it's doing it's running a Python set a PyConfigure command and so on if you want to get then all the details you can actually check this log file so let me copy this location and or actually let me push this to the background while it's still running and check this log file so here we get the output of the command that is being run during the build step with all of its output so if you do want to check on what this particular command is doing and which output it is generating we can check for it like this so using this part here output logged in produced by the trace command we can check this for the foreground and let it finish so we have the h5py installation back this completes the basic usage part I'm not seeing many questions raised to me so I think the other guys are doing a good job at keeping up with incoming questions so let me move on


So Sergey, hello, I heard that Intel are pretty good friends with Blender, right? Yeah, they're pretty good friends with Intel and Intel developers and Intel development. Nice, how do they help, how do they are even related to Blender? So there are, of course, interested in getting cycles to run as fast as possible on Intel CPUs. And they support us both by providing some access to some hardware to make sure cycles run as fast as possible on it. And they also help working on cycle source code. Oh, so actually contributing to the code? First of all, they help a lot understanding how to write good code to help us troubleshooting some performance stuff. But recently they also started to contribute to cycles directly. And just dump a bit quite big patches and quite fascinating patches. Nice, so in general, just for cycles or? So mainly it is cycles because that's one big hip thing for Intel to find out is out. But cycles is where the best knowledge is to help us gain more performance. So that's the current focus in. Nice, so it's meant to work better with newer CPUs, right? Newer devices. Yes. Because if we optimize for some newer CPU, some optimization will also be applicable to older CPUs as well. Because new market architecture doesn't arrive all every new day. So it's not like, hey, all this works, you need like brand new CPU which just came in the market. It covers a longer range of CPUs. Nice, so Intel gives you access to your hardware so you can test it? Well, one something is needed to be tested on the brand new stuff. We do have access to that hardware to make sure our changes are good. And when Intel is working on the patches, they also make sure it works on brand new stuff. So we kind of know that it's something for the future as well. Nice, so is there any area in particular in cycles that we know like we can test? So it actually worked for a few years back. So many of the things already used by many users and many productions. So they started with making sure that we use vectorization, like single instruction, multiple data as much as possible. And that was a long-standing to-do in cycles. And it was disabled for a long time just because it was slower than the native code. So that was the first thing they did. And then they just started from there, like getting test scenes, seeing where the bottlenecks are, and optimizing that part, mainly using seemed instructions. So for example, they optimized curved hair segments and triangle intersections using AVX2. That was the first thing they did. I think that was around a year ago to run on CPUs which were already in the market for a long time. And that gave that measurable speed out. And then from there, they kept working on triangle intersection because we wanted to be watertight, but also very robust. For cases, only completely 5,000 units away from the origin, which is always a pretty issue from the precision point of view. And after that, that's where I'm not sure the exact event name. So that's where they probably say, hey, how can you know this? But there is a Google Summer of Code where students participate and work on open source. Intel had something similar last year. So there was actually a Russian student, Anton Gavrikov, who was interested in getting into all the slow level stuff, and he worked together with Maxim Dmitrychenko. That's the guy I work most of the time with. And with the help of Victoria Jilin, I believe, they worked on DVH8 support. It's wider, it's like DVH3. It means, hey, every node has eight children, and then every, like all the children intersect with one command, right? Oh, okay. And so for an artist, what does it mean? For an artist, it means faster render. Faster render, okay, I understand. Yes, so for, like, the tricky part is it's quite visible in more complicated scenes. It's not so visible in default queue. It's even slower, but they started doing this feature, and it's actually now in master and it will be 2.880 initial release, even. And stuff doesn't even stop here. They also did a bucketed triangle intersection. So with one intersection command, you can intersect the triangles to one right. So it's kind of also, like, minimizes the amount of CPU ticks needed to find an intersection. So faster render. Yes, that's also faster render. Like, those speed-ups that I thought was talking about DVH8, it's actually combined with the bucketed intersection. And that's also in master now. And it's testable. And you can compare, like, before and after using, like, previous release and that's part of 2.880 initial release. But to my knowledge, they're still, like, working strong into other aspects of cycles because we also have shading. We have displacement and other stuff. There's so much room for technical side of optimizations. And to my knowledge, that's what they are doing now. And we'll see how it all goes. Wow, so we can expect more improvements on cycles soonish in terms of speed. In terms of speed, I hope so. Yes, there is one big thing which actually was started by tangent and I believe it was also collaborating with them to get in-bree in cycles. Nice. There is some technical stuff we managed to be done, but we are going to work on this. That's one of the aspects. That aspect is, like, all the shading and some threading stuff because some parts of cycles are still single-threaded. Don't say that. We can cut this. Why not? Why not? Everybody knows. But I can't say that with 2.8 multi-threading, that part which is single-threaded becomes somewhat easier. Oh, okay. That's good. I actually started looking into that a few years back and I had the initial part and I ran into limitations of 2.7, like 6, 7 design which didn't allow to multi-thread that without crashes in production files. But now all that part can be multi-threaded. Because of all the changes in the new dependency graph in 2.8? Yes, because now we don't need to worry about, hey, there is viewport which needs to access dot and viewport resolution. There is cycle which needs to access the same dot and render resolution. No, everybody has its own dot, everybody's happy. Everybody gets his candy and we can put more candies at the same time now. Wow, that's amazing. So from 2.8 and the future, we can expect cycles to get faster, more multi-threaded areas that are missing. Yes, because I don't think we can put more into 2.8, at least. Oh, yeah, now? 80-0. Yes, so it will be 81. Because 2.8 is more like a series, right? Yes, yes. We're talking about like 10 years future probably. But definitely there is more optimizations coming. So besides cycles, are there any other areas in Blender that could get optimized into stuff? Yes, so there is not a secret anymore like a year or three years now that Intel came up with Optane memory, which they are pushing quite strong to SSD segment. And the benefit compared to regular SSD is that it has faster random access. So if you need to read like this chunk of memory, then this chunk, then this chunk, it happens more faster on Optane memory than with regular SSDs. And we are trying to investigate if trying to use SSD for stuff like smoke simulation, where we have like all those random dummy and being written here and there, can be faster on Optane memory. And the particles cache can also be benefitted from this, this is like all like research state to understand that if there is any potential, there are more stuff in there. So you said one last thing. Yes, well, it's not the last thing I said. I hope so. Okay, one more thing. Yes, one more thing is to my knowledge, Intel recently open sourced their implementation of Hefka codec, which is, which was heavily optimized for Xeon processors and probably means it runs on I7s. And that part is also on the way to FFMPEG library and Blender uses FFMPEG for video IO. So that's another aspect of Blender, which gets improved into the world. So you're saying that Intel is helping the video sequencer. We can PR that way. Intel totally supports the video sequencer project. Awesome. Okay, so writing OpenGL renders, like playblasts, everything that uses video and coding, decoding. That's like everything because in Blender we come out with video from so many places. Sequencer, Compositor. The motion tracker. Playblast. Motion tracker is only reading, but that's also... That is already good enough, right? When prefetch, when we used to have Viki prefetch, then it's fine, but for the initial feeling and stuff, that's what also going to be optimized. Awesome. That's amazing. So cycles, smoke simulation with hard drive, faster and stuff. And ffmpeg. Amazing. Yes, that's quite great. And was it threaded cycles for real now in 2.8? Yes, that would be so awesome. That's like Christmas in November. Well, in the next coming years, it's going to take a while. It's good to know it's been working. Some of the stuff will arrive sooner than later. So maybe some stuff. Maybe not for this Christmas because 2.8, like deadlines. Early next year. But there are many things that are already in 2.8. So they will be part of 2.8. Awesome. Amazing. So thank you very much. Very excited. Yeah, very much welcome. Yeah, okay. Thank you.


Bah, what's up everybody once again, it's Brand Man Sean, and today we're going over the branding and evolution of Nicki Minaj. And first I want to start off by reading a quote. You can't come into this business thinking it's all about music. I just have to take control of my brand because longevity is very important to me. Everything I do, I do with business in my head. If you're not savvy, this business will eat you alive. I think that's an extremely important quote, especially coming from Nicki Minaj and especially because her brand is probably the primary reason for her success. Not to say that she's not talented as an artist or anything like that, but her branding moves have been so powerful that if you wanted to break it down, which we're about to, you'll see how her brand took her places that a regular rap skill set could not. So we're going to go over three strategies Nicki has used. But first I want to go over the three brand images that she's had throughout her career. When Nicki first started off, a lot of people didn't really know her like that. Her style was a lot more street around the way girl. As you could expect for a lot of early age up and coming young rappers from the streets. But then when she got signed to Young Money and she really started to get some traction, she went into this cocoon and rebranded as this ultimate pop princess hero. Anime, Barbie, and bright colors was a huge part of that inspiration. And this was important to her, particularly for that long term play. Particularly because you don't see a lot of rappers make it into the pop world. She's definitely the first woman to go as far as she has, primarily as a rapper. All of that had to do with that Barbie image and that entire phase where she created that character. Think about a song like Starships. It's the least street song that she's probably ever done. As a matter of fact, they have a kids bop version of Starships. Near the end of this second phase, she also even pushed into American Idol, just constantly being positioned in front of the other side of the industry. And what's so important about that phase is getting out there and getting that awareness from people who normally aren't really looking and checking for hip-hop artists to get a look at you and then bring them back into your world. Allowed her to have a lot more stability because we already know the hip-hop world is fickle. And especially when it comes to women, it seems like it could only be one at a time. That solidified her fan base because she's so far and beyond where any other women has achieved. Even with Rimi Ma going up against her and kind of threatening her hip-hop stance, if she lost their main hip-hop fans, she would have a lot of fans left who don't even really care about the nuances and aggression and what goes on at the core of the hip-hop world and community. This is that longevity that she mentioned in that quote earlier. And her third phase is pretty simple. Third phase represented more of her mature, evolved, and sexy woman. Timing was perfect because she was getting out of a long-term relationship and that's always a great time, it seems, for women to reinvent themselves. Society understands it. Media loves it for a great narrative. And that kind of gets us to where we are today. And now with three strategies that has helped her out in her career. Number one is brand association slash partnerships. Signing the Young Money was great for her, especially the amount of effort and energy Lil Wayne was giving her and Drake at the time. Being aligned with them basically allowed her to have cool points. Same that it did for Drake. When you'd have brand association, you are basically borrowing someone's fan base, someone's perception. It's basically like if this person approves, then they must be cool. That's why companies do partnerships. That's why certain stars take pictures together, even though they know they aren't friends. It's just a part of the game. And that brand association is very important for her second strategy, which was a unique brand identity. And the reason I say that is because the most powerful part of Nicki Minaj's brand is hands down her voice and the creation of the Roman character. All these crazy voices she was doing, nothing like it comparable in hip hop that has been done, especially not on her level. As far as the unique delivery is more powerful than amigos and futures. As a matter of fact, it's so powerful and it's so out there that you don't really see anybody else doing it like that. And the reason why is because it sounds crazy. Just point blank.  But that's what got people's attention. And then when you add the brand association that she had with Young Money, it allowed people to at least say, okay, there has to be something here.  That was basically the process Nicki Minaj went through in terms of that flow. People were definitely laughing at making fun of it, but it also helped her get more and more attention, helped to get out there, helped more people find out about her. I'm just waiting to find out how she came up with the idea to really stay consistent with that flow and take it seriously. Because in my mind, back when there was nothing like this before for her to come out into the world seriously doing this, that took a lot of courage. And then the rest of the unique brand identity things I kind of alluded to when I was talking about the second phase of her rebranding. But number three, cultivating a strong core fan base by branding her followers, the barbs. It was already perfect because she was walking around looking like a real life Barbie. It allowed her fans to not only just watch the world she created, but feel a part of the world she created. And as she continuously cultivated that fan base, that allowed her to go from fans to actually having ambassadors. And this is why when people come for Nikki with that negativity or Rihanna or Beyonce with the beehive, their ambassadors, they ain't having it. Because you're no longer threatening just Nikki at this point. You're threatening the entire world that they created together. I could go on about Nikki for days, but I won't. If you guys feel like I miss anything, definitely put it in the comments below. Other than that, that's it. Y'all know what to do. Hit that subscribe button.


So we move to the second talk, which is called Shuffle Arguments Securing the Degeneration Model by Prasoudi Fosey, Elger Lipma, and Michel Zajac, and Michel is giving the talk. Yeah. Hello, everyone. Let me talk about our result, Shuffle Argument, Securing the Generic Billionaire Group Model. So what we actually basically is a new efficient CRS-based non-interactive zero-knowledge shuffle argument. And this argument is over four times more efficient in verification than previous work. And here, we argue that verification time is much more important than proof time. It's because usually in the non-interactive zero-knowledge setting, you usually proof once something, and then you probably need to verify many times or by many, many participants. And our soundness proof holds in the Generic Billionaire Group Model. Now, this is quite complicated. The proof is quite complicated. Maybe there's no high math in here, but the level of complication comes from the huge number of polynomial equations. So we use the computer algebra system to solve it. Especially, we needed to go through Grubner basis. So let me talk about motivation for Shuffle Arguments. One of the motivation is e-voting. In the e-voting, we have a voter, say Bob. Bob wants to vote in some kind of elections. So he uses his computer to send his vote to some server. And then the server counts the votes, and everything is perfect. But as history tells us, it's no voters who counts, but who counts the votes, right? So MixNet give us two properties, anonymity and correctness. Correctness comes from the fact that data is public, and anonymity comes from the fact that data and source of the data is private. OK, so simple MixNet. We have a few voters. Voters send an encrypted vote to a MixServer. A MixServer then gets some random permutation along with randomness r. And what MixServer does is he gets input ciphertext permuted using permutation pi and randomize them using randomness r. Then the server sends it further to another MixNet server, say MixServer. And the next server does exactly the same. But of course, it chooses permutation pi and randomness at his own. Then everything goes to the some decrypting machine that knows secret key, and this machine publishes plaintext. Of course, we can have much more MixServers here. The security assumption here is that if at least one server is honest, then the security holds, then the data is private, and then it's correct. OK, so this setting gives us privacy against each individual server, because if this server is honest, then the next server knows nothing about which ciphertext comes from which user. But OK, what if server cheats? So here we cannot do nothing in this setting. So we need to change it a little. We give every MixServer additional public key, and we demand that every server proves that he has done this shuffling work correctly, so that he honestly output permutation of ciphertext. It means that, in fact, this D here re-randomized ciphertext C and send this proof with new ciphertext to the next MixServer. The next MixServer verifies all the previous proofs, shuffle ciphertext, and sends them on. And in the end, the crypting machine verifies all proofs. So here we see that the verification time is more important because every server proves once, but it verifies all the proofs from the servers that were in this line before him. So in this setting, we have both anonymity and correctness. So shuffle argument, we give efficient zero-knowledge argument of correctness of shuffling. As I said, the MixServer permits ciphertext, re-encrypt, and provides a proof that it was done correctly. But the problem is that in the CRS model, existing arguments were not very efficient. Here we have a small comparison. In this paper, we achieved much better CRS length. And it matters because this end here is a number of ciphertexts. So in the national election, for example, it can be like 10 millions, 20 millions, or more. In communication, we do much better. And here, compared to Fauci-Litma paper, we do a little bit worse in terms of prover's time. But on the other hand, we are much better on this verification phase. Furthermore, we achieve full soundness. And we work in the full generic blaner group model. Usually, shuffling argument is quite complicated. So usually, known assumptions about blaner groups are not enough. They don't fit well because they are usually quite simple and they don't give us the old properties we needed. So up to now, there is usually the case that the shuffled arguments use some quite new blaner pairings assumptions or even introduce a new one. So we get rid of these assumptions in some sort of way. OK, so I think this slide appeared a few time already on this conference. But let me remind you what is zero knowledge in a CRS model. So we have a trusted third party that produces CRS, common reference string. We have prover here and verifier here. So the trusted third party sends the CRS to both parties. Prover knows some instance of problem along with witness, while verifier knows only the instance of a problem. Then prover sends a proof pi that, in fact, x belongs to some language L. He proves that he knows witness w. And then verifier accepts or rejects. Of course, in every zero knowledge setting, we need simulator. In the CRS setting, simulator is given some additional power called trapdoor. And the simulator, who knows trapdoor but doesn't know witness, simulates the proof that x belongs to the language. So basically, we have three properties of every zero knowledge argument. This correctness, that means that the verifier accepts if the proof is correct. Soundness, that means that it's hard for a malicious prover to make verifier accept if x doesn't belong to language. And zero knowledge is defined by this simulator. OK, so let me tell you something about Billiner pairings. Billiner pairings. So we have three groups of the same order. We denote them by g1, g2, gt. We know generators of these groups. And we have Billiner map. It's a function from g1, product g2 to gt. And the requirements are that they are efficiently compatible, non-generate, and, of course, Billiner. And there are some assumptions about pairing. The very basic assumption is that inverting pairing should be hard. So given the pairing on A and B, it's hard to compute either A or B. So this is like equivalent to discrete law. Given g to the A, it's hard to compute A. But what else should be hard? It's not enough. So in a shuffle world, it usually looks like this. We have some protocol. Then we have a bunch of assumptions on Billiner pairings. There are hundreds of them, and many of them introduced in the last few years. But as I said, the shuffle argument is a quite complicated argument. So to make protocol efficient, we usually needed to introduce some bunch of new assumptions. And how to verify these assumptions? Usually, we verify them in a generic model. So it's like a minimal requirement for an assumption to hold in a generic model. So this setting is not bad if these assumptions are well known and well justified, or if we don't introduce many new assumptions. But in fact, here, we need to bend our protocol to make it fit to these assumptions. So it comes with loss in efficiency. So what we use in this work is a pure generic model. So we were able to simplify this picture to this. So we know that the generic group model holds only for some restricted adversaries. But on the other hand, it's very, very efficient. So in a generic billionaire group model, you have this assumption that this adversary has only restricted access to group elements. Like he knows group operation, billionaire map, and can do equality tests. And if he wants to compute some element in G, he needs to know two elements in this group that gives him this element. So basically, if there is an element in a group, in a billionaire group model, then we know the discrete log of the polynomial that creates this element. And well, in general, in a generic billionaire group model, we use GT as a generic group. Here, we use something called semi-generic billionaire group model because we don't handle GT as a generic group. And this comes from the fact that a lot of billionaire pairings has this group GT as some finite field. So it's hard to restrict access to elements of finite field. So how soundness in the GBGM looks like? So trusted third party chooses some number of random variables and produces CRS. CRS is a set of polynomials on these variables, and everything is given in exponent. Then adversary can get elements from the CRS and make any linear combination of it. And then what we do is we do some quadratic tests. We use billionaire maps, and we check whether our verification equation holds. So we need to make sure that every verification equation is zero. So in general, adversary chooses coefficients HIA, and then we check this set of equations. And we need to show that the solution we get, the only solution we get is somehow nice. And that means that adversary cannot deviate from the protocol. So when we constructed argument, we need to decompose it to the smaller building blocks. We decompose it to the subarguments. And we demand that every subargument is efficiently verifiable. So we make sure that every subargument is sound independently. And then, of course, it may be the case that we need some CRS elements to prove soundness of one argument. And the CRS used in every argument separately, it is not the same CRS. So we need to compose all the CRSs into one big CRS. But then if we add element to CRS, adversary becomes more powerful. So we need to check again whether this protocol is sound. And if it's not sound, we usually add a new random variable that will be used only in this subargument. OK, so our subarguments goes up follows. We start with permutation matrix argument. And in this argument, prover commits to some permutation and proves that he committed to it correctly. Then there comes consistency argument where prover proves that he used the same permutation as he committed to shuffle ciphertext and validity argument, where prover gives proof that ciphertext is formed correctly. So correctly means that the soundness proof holds. So in fact, he cannot a little deviate, but all together we make sure that he does. OK, so let's focus on the permutation matrix argument. So what's permutation matrix? I think it's clear. So we use two subarguments in this subargument. First, that the matrix is statistics. So the RAMS rows sum to one, one vector. And then each row is one sparse, at least that at most one coefficient is non-zero. OK, so one sparsity argument looks as follows. Prover commits to elements in a, it's basically it's a Pedersen commitment, but in exponent in this notation. Then comes argument from the square span programs. Proves looks as follows. And verification equation is just a quadratic equation that uses these AIs, some elements from CRS. OK, uses the proof given by a prover and then checks whether this equation equals zero. But of course, adversary can deviate from the protocol. So here's the form of AI given by an honest prover. But in fact, adversary can produce AI in a very different way, right? So as I said, he can get coefficients next to the every element from CRS as he wishes to. So he can produce his own AI in a very sophisticated way. The same comes with A2. And of course, he is not restricted to the previous way of getting pi. He can as previously get every linear combination of CRS elements he wishes. But still, the verification equation is out of his hand. The verification equation is like given in a system and it's checked by a verifier. So it's still the case that this verification equation holds. As I said, the idea of the proof is to make sure that here, let's say here, the adversary cannot come up with something different than honest prover. OK, so how solving system of polynomial equation looks like? So we need to find coefficients such that this verification equation holds. And we begin with noticing that next to the every such variable built from the product of variables, it's linearly independent. So we can focus on coefficients next to the such tuples. So we know that if the whole verification equation is to be 0, then every coefficient next to the such tuple needs to be 0 also. So this gives us a system of polynomial equations and the system is huge. Maybe 20 polynomial equations is not huge, but let me remind you that we are talking about sub-argument of sub-argument. So altogether, we have a lot of polynomial equations. So that's why we use a computer algebra system. So this is an exemplary system of equations. And here comes the solving. So we mix computer algebra system with manual labor. But that is probably we are not so good in coding. Maybe we can get everything from this CAS system. And we use linear independence of polynomials given in CRS to split some coefficients to get more and more equations, but simpler ones. We compute the Grumner basis and then solve the Grumner basis. And this can be, of course, done manually. But we use the computer algebra system. And finally, we obtain that this AI is in fact as honest prover would produce. Thank you very much. We have time for one quick question. In terms of communication or? OK. So let me begin with the fact that the Bayer-Groff is very nice protocol, but it's interactive. In terms of communication, I'm not sure how we compare to Bayer-Groff in terms of communication. I'm trying to go back to the table. Well, there is some problems with communication because in every case of shuffle arguments, you need to send over the web like millions of ciphertexts. So basically, the order of magnitude is still pretty bad. There's still a lot of stuff to do. We need to send. So we didn't focus it very much. I think I skipped it. So where it is? Well, communication is seven and plus three. So I don't recall now how this looks like in the Bayer-Groff settings. Oh, right, right, because they don't use sublinear stuff. Yes, so we do the math wars here. OK, let's thank Michel again.


The nature of our economy is one where we cannot afford what is traditionally called the trickle-down approach, which is where we're just working on industry and working on business and hoping that if we create enough industry and create enough business, people will be employed. That way, yes, people will be employed, but it will be too slow because we have a large, very large population of extremely poor people, very large. So we must address the questions of the bottom of the pyramid at the same time as we are addressing the questions of industry and all of that to create jobs. And so one of the critical things that we're doing is looking at how to resource the bottom of the pyramid, how to give credit to the bottom of the pyramid so that they can earn, so that those people at the bottom of the pyramid can do their business, which is all usually informal, informal trading, they can continue to do their business, they can do their work, and they can also make their own contributions. So what is called the trader money scheme or the market money, depending on which one it is, this is a credit scheme that has been given to almost 2 million traders, 30 traders. We believe that by giving them money directly, and these are people who are already in some trade or the other, they're able to improve their inventory, they're able to do more of their trade and get out of poverty because the very first thing is to get people out of the desperate situation of poverty. And so we have to almost invert the process such that the very poorest, the lowest also have resources which is usually open to the other.


Ukrainian President Volodymyr Zelensky met Turkish leader Tayyip Erdogan in Istanbul on July 7 after visits to Bulgaria and the Czech Republic, part of a tour of some NATO capitals aimed at encouraging them to take concrete steps at a summit next week towards granting key of membership of the alliance. A key element of Zelensky's talks in Istanbul will be the fate of a deal, brokered last year by Turkey and the United Nations, to allow for the safe export of grain from Ukrainian ports via the Black Sea despite the war raging across Ukraine. The Kremlin said it would be watching the talks closely, saying Putin has highly appreciated the mediation of Erdogan in attempting to resolve the conflict in Ukraine.