 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. So we have to be a little bit careful here because we have a star and a small regular expression. 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. Then the next exercise is the dry run mechanism. 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