 Good afternoon everyone and welcome to the next edition of the Bar Accel webinar series. My name is Rosson Apostolov and I will be today's host. Today we will present you a very interesting talk on one high-level framework for development of parallel applications, the ComSets framework, and it will be presented to us by Daniel Letzi from the Barcelona Supercomputing Center. Barcelona Supercomputing Center is one of the main partners in BioAccel, and they are working on the development of such frameworks for parallel applications. So for those of you who are new to BioAccel, I want to give a very brief overview. BioAccel is a center of excellence for computational bio-regular research, and we work in three main directions. One is the improvement of the performance, scalability and efficiency of several key applications, extensively used in bio-molecular research. These are Dromics for molecular dynamic simulations, typically used HADOC, which is used for integrative modeling and docking, and also CPMD for hybrid QMM simulations, for example, of enzymatic systems. In addition to the main codes, we also work extensively on the development of efficient workflows and packages associated with data integration, which have the main aim of improving the productivity of researchers, so that in a very easy and user-friendly way one can bundle together different applications to scripts and easily submit them to clusters for large-scale computations. And today's presentation is, in fact, on one of the main results of the work in BioAccel in this direction. Comcess is one of the main platforms that we work with. So in addition to working with the software and with the workflows, we also have a lot of effort on training, consultancy, we're promoters of best practices for usage of applications for code development, and we work a lot with end users from academia and industry. We organize the work along several interest groups, which we invite you to join. You can find more about it on our website and visit our discussion forums and browse through our code repositories and visit the chat channel. With that, I would like to present our today's speaker, Daniela Letzi from Barcelona Supercomputing Center. Daniela Letzi has a PhD in IT technology engineering from the University of Salento in Italy, and until 2008 he's been a researcher at the Center for Advanced Computing Technologies at the University of Salento and member of the Euro-Mediterranean Center for Climate Changes. Since 2008, he's been working at the Barcelona Supercomputing Center as a researcher, and his work focuses on high performance, distributed and cloud computing with the associated programming models, specifically focusing on interoperability. He has a very broad experience, he's been working a lot of European-funded projects, of various sizes, and he's currently involved in the Mobile Folk to Cloud project, the land support initiative, and he's one of the main people in the working on workforce in BioExcel, as I mentioned already. And you can find him on Twitter with Lezidon Twitter handle. And with that, I'd like to change now to Daniela to start with the main talk. Okay, good morning everyone. So in this presentation, I will introduce the COMS programming framework and how we use in the BioExcel initiative. I will do a very short demo of the workflows that we implemented in the BioExcel around molecular dynamics using our framework. So when we talk about programming and application, we have many challenges that we have to face. The first is what is the magic that we realize to face these challenges? So we make with COMS, in this case, things executed in non-parallel, for example. First of all, the first challenge is the heterogeneity of the variety of computational platforms we have to deal with every day. So we have new architectures, that means organizational processors, processors are designed with multi-cores, many cores. Now we have a lot of usage of GPUs and accelerators and FPGAs. So this is a very important issue that we have to deal with because of course we have to run an application, which is supposed to be one code on different backends with heterogeneous architectures. So the idea is when we talk about high-performance computers, we shift from the sequential way of thinking the application to parallel. So another step that we have to introduce in our schema. So using possibly new instruction sets, new languages, SMPI, OpenPA, etc. And we have every day new computing parties. We started with a cluster, then there was the idea of read computing in the 90s. Then we have the era and we are also in the era of clouds. Now what is missing in this slide is containers as you may know. So different challenges related to different computational platforms. So when we talk about programmability, programmability is the capability of programming something, but we have to do it in the proper way. We have to be good programmers and provide to our users programming models that are easy to be used by the application developers that are able to provide the expressivity to the user in order to program in the proper way the code and reduce as much as possible the lines of code. Of course we need to provide semantics functions that is the life of the developers. The main blocking factor when we talk in parallel is the fact that in a way we are sequential. So we may think that something can be done in parallel, but still we think about communications in a sequential way. So in the end when we work with our users that comes from the scientific communities, they are used to work with programming languages that are thought to be used to execute sequential applications. So when we shift to parallel programming, one of the first things that we have to change is the fact that the user on his own has to express their parallelism, has to think about how to distribute the data in order to enable this parallelization and to also synchronize and perform their communications typically in MPI, for example. So the things are getting also more complicated when we want to distribute the application on distributed environments. As we said before, we have a multi-course. So when we distribute things, we are in many cases using a heterogeneous infrastructure as I said before. So we have one cluster that can have multi-course, another one that can have just GPUs. We have to distribute across multiple nodes the part of the application that want to parallelize. And also we have to deal with the memory that in this case is distributed. And above all, we have a lot of middleware to manage the resources. We can have from HPC to managers, to cloud managers. For example, Amazon, Google, they provide their own management system. And now we have, as I said, containers, technologies. So with all these problems in mind, related to the programming of application on distributed system, we have our vision here you see since many years on how to develop programming frameworks that can, let's say, abstract these difficulties to the final user, let's say, to the applications. So the idea is that the programming model should enable applications to be agnostic of the computing platform. The idea is that this programming model layer should be high level, as clean as possible and abstract to write the applications. And on the other side, having a powerful runtime that can perform the optimization, parallelization techniques on those applications. And that will take care of all the intricacies of using the underlying technologies, for example, to execute the same application on the clusters, on grids and clouds, etc. So with coms, you know, coms mean com superscalar. So what is a superscalar programming model? The idea of the superscalar programming model comes from the superscalar processors, where the idea of the superscalar processor model is that we have a task that is a unit of work. And these tasks are executed in out of order when there are no dependencies related to each task. And so the same idea coming from this superscalar processor is being adapted to the programming model. So the idea is that the applications are built, are programmed in a way that the runtime of the programming framework is able to build a task graph that express the potential concurrences between the invocation of the tasks. And so this runtime is able to make decisions on when and how and where to execute a task and offers abstractions to different backends related to, for example, computing and storage. So this means that a user can write the program, the application, and they can also configure the runtime in order to execute the same application as an important feature of our programming framework on a quite large variety of computing infrastructures without changing the code itself. So the main elements of this programming model of superscalar programming model are the superscalar program that is made of the sequential code of the user. So the user doesn't have to parallelize the code. We are not introducing here a programming language SMPI where the user has to write from scratch in case it's the application in order to be properly parallelized. So the application is sequential. We have a single, we have a shared memory space. And we have to identify the task. I will show you shortly how this identification task is performed. So the task is set before the main element of the programming model is the computational unit. This could be, for example, in an application function of a certain granularity that operates on some input parameters and variables and produces some output. The task can be, as I said, it can have different granularity. The granularity means the amount of work that is performed inside the task is inside the module, the function. And depending on this granularity actually we have here at BSE at least different implementation of the programming framework to deal with the different granularity models. So this task, when executed, this is important, is execution is independent, at least the execution itself from other tasks. The only dependencies we have are data dependencies, but these are managed by the runtime. Related to the syntax, there is no language, there is no API itself, what we have are task annotations. So the user has to identify the components of this application that are candidates to be tasks to be executed on a given node, on a given slot of the available computing infrastructure. As to provide a description of these functions of this task in terms of arguments type and directionality and eventually provide also some synchronization. So this is not something very common, but we can provide some code that allows the user, for example, to perform synchronization between the calls to the task. So here at BSE we have two main implementations of this idea of the superscalar programming model, which also is called a task-based programming model. So we call this the idea as task-super-scalar, star meaning whatever, super-scalar, and then we have two main implementations. We have the coms implementation, then we have the coms-py-coms. We use the term coms-py-coms, we mix a bit the definitions. We started with coms, but then with the advent of Python. So we interest on this kind of, on this language. We also adapted the name to, so the difference mainly is that we have the same idea of the task as a basic unit of work, but we address different kinds of applications. We work at, for example, in a cluster at a level of a node. So we have shared memory, architectures, we have GPUs, so we are in a cluster, and above all the generality of the task is quite small. We are talking about microseconds, milliseconds. While on the other side with coms, we deal with more post-grade generality where tasks are composed of methods, maybe programs, simulation that can run from a few milliseconds to days in many cases. And in the case of coms, the idea is that everything is executed in memory, so the dependencies are in memory. While in coms, we deal with the distribution of files. We realize parameters as objects. And it was related with the language support with coms, users can write application in CC++ and Fortran. Why do it coms? We have Java, which is the native language of the coms around them. And then we also can have application of written in CC++ and Python. So as you can see here, we go from a pure cluster computation to a distributed computation with coms with clusters, because to us a cluster also is a distributed environment because we consider each node of a cluster as a separate entity. Let's say it's a separate slot where to execute tasks with clouds, grids, etc. So programming with coms. Again, the idea is that the code is still sequential. So the user has sequential code, sequential application. And what we do is to annotate this code to identify the tasks and the directionality of the data. The directionality means that, for example, if I have an integer in the call of a task or a method of function, the user has to say that this integer is an input of the task or it can be an output or it can be also input output. Based on this information on what has to be executed in the house or what are the parameters of the application, the runtime builds a task graph that express the potential concurrency of the execution of that application. This is the basic idea. This is important to understand the coms. The basic idea is that we don't do any magic, let's say, as I said in the first slide. But what we do is we try to exploit the potential of implicit parallelism that we have in many applications. You can, for example, consider a typical part of a code, which is a for loop. We call several times, depending on the number of iterations. So we call the same code many times, but maybe with different parameters. So depending on the type of parameter and on the directionality of this parameter, each call can be independent of the other. So, for example, if you see this example graph here, you can see that in this case, we have the green pallets at the beginning that are independent of the other. The only dependence is the input that they receive from the main program. But this means that depending on the number of nodes that I have, I can execute all these tasks in parallel on the available nodes. So this is the basic idea of, of course, expressing the potential concurrency of the execution of the task. So there is no identification of the parallelism inside the code, explicit parallelism inside the code. And, of course, the other important feature is the fact that this code that we annotate is agnostic of the computing platform. It's the runtime that enables the interpretability with different decents, in cluster clouds, in topical containers, et cetera. So, in the case of pycoms, so the Python is an example you can see here that you have a regular Python code with no parallelism anywhere. And we use decorators to identify the task inside the Python. In coms, in general, we have two kinds of annotations. The task annotation to identify the coms. But very important because it can drive the, or can force the scheduling of the runtime. This is because, from what I said, we have the definition of the application here in the programming model. And the user can specify, for example, the number of processors needed to execute that specific function independently of the actual infrastructure. On the other side, as we will see later, coms has a description of the real platform where the application is going to be executed. Based on this description of the resources and the description here of the application, the runtime matches those requirements and decides where to execute the task. As I said before, we don't have any API, but we have some small, very few API internals to, for example, synchronize the execution. This is, for example, used in Python to synchronize a future object as a result of the execution of a task. In general, the coms weight on is used to block the execution of an application until all the tasks of that part of graph are executed successfully. So this is an example of Python. In Java, because of the different features of the languages, we have a separate file that we call annotated interface. So it's an ITF.java file that comes with the Java file where we do the same as in the Python case where it is expressed in a separate file and using a Java annotated interface. So, for example, in this case, we have the align function. In Java, they take several parameters. All but one are input parameters, and there is just one out, which is the result of this align method. And we have the part that specifies the constraints. And here we can find another annotation in coms, which is the binary annotation. All the... I'm not going to show all the possible annotations in this presentation, but of course you can have a detailed description on our documentation. The binary is... The binary annotation is very useful because it allows for the execution of an existing binary that implements the specific task. This is very common. We deal with many of these cases because in many... As I said before, in our experience, we have collaborations with the scientific users that already have applications. Also here in the Excel, in the end, we do the same. So the idea through this binary annotation is to provide support to an existing binary in a more clean and easy way. So in Java, you can have part of the description of the task also where the method is implemented, which class, Java class, the method is implemented. And as you can see here, this lower part in the main code, this function is called as it is. You can see here there is no actually... There is no coms here, there is no specific language here. So this could be considered as the sequential code of the user. That if you execute in a sequential way, it would be same as executed in coms. The only difference is that coms uses this description to parallelize where possible, respecting, of course, the sequential integrity. We parallelize the execution of these assembly partition tasks in a proper way. So from the point of view of the user, the execution is exactly the same as without coms. The only difference is that with coms, the code is executed immediately. This is because coms, as I said before, intercepts somehow the calls to the user methods and substitutes these calls to invocation to tasks in a remote node of a cloud or a grid, for example, or a cluster. But the execution will keep, of course, the sequential integrity and coherence of the regional sequential code. So this is a brief introduction to the programming model. As you can see, it's quite easy. Again, the complete description of the programming model is available in coms documentation. So talking about where we can execute coms applications. So our architecture is simple in the sense that we have a programming model part, as we have described so far, where we have the support for Java, Python, CC++ application. And then we have a runtime, which is transparent to the user. In the sense that the user doesn't know, of course, the runtime details, but has to configure some file in order to tell coms where to execute things. And we supported quite a lot of infrastructure. We have support for clusters. Here, when we say cluster, we mean a queue management system. For example, here, BC, we are not an awesome way that this works with this rule. So we have an adapter for this rule. This means that the user can include an entire coms application in a cluster. And the coms deals with the allocation of resources of nodes and et cetera. We have supported to class. We worked a lot in the last years with clouds. We have interoperability with many providers, as for example, open Nebula vacancies, open stack, Amazon, Google. We have a connector. We have connectable connectors, part of the runtime that can be configured for different vacancies. We have a connector with J clouds that gives us interoperability with many different vacancies. Also, for example, Microsoft Azure. And coms is also able to talk with Docker. So we have a coms Docker image. And this Docker image can be in general a Docker application that is packaged as a container, can be executed with coms. And for example, one other backend that we are talking about is Mesos that you may know is a quite big source management system for containerized platforms. And so once we know that we have this interoperability, how I can select the execution platform. So it's quite easy. So just as a brief introduction to the runtime details, the coms runtime is made up of different small components. And what the user has to do for executing, sorry, we have components for the generation of the graph. This task analyzer is the component that is responsible for the generation of the task graph that is used then to expose the parallelism of the invocation of the task. We have the scheduler that based on different pluggable scheduling policies decides how to execute the task and where. And we have then different plugins for the source management, as I said before, so for different source providers, for clouds, for containers, and also for, yes, so we have support for different persisting projects, protocol and communication protocols. This can all be configured depending on the user needs. So the configuration of the coms for the execution in a specific infrastructure is done in this resources component providing two simple files. We have a description of the other sources that are available for this execution. This means that here the user can describe, for example, in the case of a cluster or a cloud, how the nodes are made or, for example, how many processors each node, the memory, the size of the disk, et cetera. And then can configure to another file, the project file, how to access those nodes. For example, the project, the user usually provides the dates on how to connect to an Amazon cloud, so the project user can provide the key, the secret to connect to Amazon, et cetera. So through the proper configuration of these two files, the same application, again, I want to highlight the fact that the same application can be executed on different back ends. Also, we have a lot of tests where the user can execute the same application on an intro genius set of resources, a typical test that we do in cloud is to start the application in a cluster, but then comes also a configure to be able to use a cloud as a back end where no more resources are available in the cluster, it's a typical case. So we have hybrid execution of combs. There is no limitation in the sense. So this part of the connectors is responsible for this. But cloud is very powerful how we implemented the cloud support because we enable elasticity for the user. As you know, with clouds, there is this idea of virtual resources that can be created and destroyed on demand. In this case, it is the combs runtime based on the actual load of the application, so based on what is currently ready for execution in the test graph, combs can ask for more virtual machines to a provider with the task. And so you can, for example, a big part of your application that requires a lot of task execution. In this case, combs understands the text of this necessity and asks for more virtual machines to a provider. Once this peak is over, the resources can automatically destroy a lot of the users. So the application usually, as you can see here, are executed to a simple script command, which is the run combs command. And depending on where to execute, we have different options that can be provided to your combs script. Again, all the details are provided in the documentation. So maybe I can skip this part to make the demo in the end. So you can have different configuration of combs. You can execute your own local resources in an interactive way. It means that you run the master. We call the master the part of the application, the main part that is analyzed by the run and that generates the task that are executed on the distributed nodes. Distributing the nodes means that the task code is sent to workers, we call the workers part of the combs run time that takes its input, the task itself, and executes the code on the remote resources and sends the results to the run combs. So this is the most simple way of executing combs, for example, on our laptops for testing. Then we can have, as I said, in the cluster, we usually connect to a login node and instead of using, for example, run combs, we use NQ combs. In this case, the application, the resources are not provided by the users because we have an automatic description of the resources because, as I said before, combs is able to talk in my nostrum, for example, with the slope. So in this case, it's the run time that allocates the resources on behalf of the users and knows when the reservation is ready and takes care of using the pool of resources that are being provided. In the cloud, in the cloud, we have to configure the specific cloud connector to be able to talk with the provider API. So in the case of OCCI, that is a public standard, that you, for example, the European Infrastructure Federated Cloud, the user has to provide the credentials to access the providers and instantiate with the machines. In these slides where you have access, for example, we have a video where we use the Google Cloud platform. So if you have time, you want to see it. We have our channel and you can see a demo of a combs application executed in the Google Cloud. In Docker, as I said before, we use the compose to describe applications and to deploy applications as a set of Docker containers. In Docker, you can have different possibilities. One option is to use swarm. Docker swarm is a way to be then deployed in a Docker cluster. So once you have this one cluster configured, you can execute a combs application as a set of Docker containers. In HPC, given the constraints and requirements that we have on the usage of containers, we can use the singularity. For example, we did several tests with the combs in my nostril using singularity on a small set of nodes. Actually, containers, I'll show you after, is something that we are working along with. So containers is the state of the art for the distribution of applications. It's quite easy, and for us, it's very powerful. We're working a lot also in the content. Something we also, which is very actual, is how we deal with the combs, with the convergence between HPC and the database. So we have the objective to provide a programming methodology to develop complex workflows where we have a large simulation, for example, the application that are made of MPI simulations that can run in a supercomputer, together with the data analytics parts. What we call the dynamic workflows. We have a high-level part that calculates data analytics models, and based on that, we can then instantiate an MPI execution on a supercomputer. So we're working a lot with this. It's our ambition now. We are going to combine these two worlds, the HPC and the data analytics world. And we are working a lot both on the programming side, of course, in order to provide the abstraction to the user, for example, to program with combs streams and for data analytics. And on the other side, we're also dealing, with different storage patents that are today available, for example, HDFS, or RADIS, or other technologies that are developed in-house here, yes, TES, data play, or persistency, et cetera. And also something very powerful. Now we are working on kind of storage, in-view memories, sort of intermediate layer for storage between the disk and the run with the persistency, something that we are working on. And this slide also too, because when we talk about combs, we said it's very powerful, we have a lot of users, et cetera. But many times we have the question, okay, but what about Spark? Because Spark now is sort of the fact of standard when we talk about big data analytics, et cetera. So we did, of course, our comparison in the last years with Spark. We improved a lot our performance, also the expressiveness of our programming language. The architecture can be compared, actually. We have the programming model of combs as the Spark code. And on top of combs, we have developed a lot of being an algebra modules, algorithms, parallelized with the combs. We also have examples of application developed with the TensorFlow and executed with combs. And we are in top of, as I said, with different computational and data infrastructure. We did. And these results are published in papers. We did also comparison in my nostrum of similar implementation of data analytics blogs with both combs and Spark. And in many cases, as you can see here, we performed, we have performed Spark. So this is why we call this comparison David. This is Goliath. Of course, we are small compared to Spark in the sense of the distribution of the usage of the tool. But we think that we are doing good work because the numbers are on our side many, many times. So these numbers many times. What our success stories. We have a lot of users of combs. Mainly, we develop combs, we enhance combs, introduce new functionalities, through the requirements that we receive by our users in the project that we are involved in. But our strong, let's say, partners are from BSE because BSE is internal users of the departments. One of these is the earth science department and the life science department. Our main relations. This application, the NMMB is a model. The NMMB is a model for dust prediction in this being developed by BSE collaboration with the national centers with the NOAS in the states, with the NASA. It is a very complex application for climate modeling. Here we have a multi-scale online atmospheric chemistry model. Where in the end they model how the dust moves in the atmosphere and based on these movements they can predict the weather. How this dust, for example coming from this heart in Europe affects the quality of the air in Barcelona or in Europe. And this code is multi-scale in the sense that they can execute this simulation of different scales from original scale to global scale. So this drives the amount of computation to be performed. And talking about the requirements, this code at the beginning was a combination of external binaries and case simulation and Python of course. There are a lot of different modules that actually were in many cases a bash script. So what we did with them was to implement a workflow a complex workflow that from the programming level is easier to be read and to be composed and on the other side runs in a supercomputer in a optimized way. Just as an example we have we introduced the native MPI support in POMS based on this application of requirements. So now you can specify as annotation your code as an MPI. Specifying for example how many compute nodes you need for this part of the workflow and how many computing units in how many threads is inside each node. Based on this information comes from the users and allocates the proper number of resources where to execute the MPI part of the workflow. This is not clear but because it's very complex. This is the task graph. This is what comps executes. So you can say it's quite complex. There are several iterations there are parts that are MPI and they are non-NPI processes for post-processing and there is the final image generation because in the end they produce maps of the movement of the dust in the atmosphere. So stepping in via Excel I already introduced what we do in bioexcel as part of the work on workflows we together with IRB yet with Barcelona we define the set of building blocks as base for the definition of workflows for example for the molecular dynamics calculations. So the idea here was first of all a rational implementation of the task of the building blocks of an application in order to be interpretable. So we use in other implementation infrastructure and Gnostic and we use pycoms to implement as workflow manager to execute and orchestrate the execution of all these building blocks. So you can see here on the right is the sketch of the workflow in terms of building blocks and here we did many tests on different infrastructure via Excel from clouds to dockers and supercomputers actually now we are performing large test involving 40,000 goals in my Nostrum we are waiting for results we are adjusting things with the final picture and so coms is dealing with this kind of simulation where you have the massive protein mutation calculation so this means that each of these traits of this line calculates a different mutation of the proteins I'm not an expert of the matter so maybe I use wrong words but anyway from our side what we do is we calculate, we distribute this big part of the application that comes from different proteins into a mutation sorry mutation in the end we have this kind of graph so you have a thread for each mutation and this is the output of the of the execution of the workflow so I don't know if we have how we are in time but my idea was to maybe we cannot execute so as I said we are working a lot with the containers so we have a coms container doctor image and here for example we have an implementation with the Jupyter network of this AMD setup so this molecular dynamics workflow that we implemented in Bayer Excel and that we are going when validated we will also publish as a separate doctor container for distribution as such stories of Bayer Excel so here what I wanted to show is how the workflow is implemented quite a great use version of the workflow so but this is to show first of all that you can work with notebooks with Jupyter this is a very easy and nice way of testing and things so you can start a coms application as a Jupyter notebook using pi coms as interactive Python model here as you can see what we are doing is instantiating the runtime so this is what we will do usually from the command line the run coms command line so here we are saying that we want to execute the AMD setup application I am preconfigured the resource and the project files to use my local resource on my laptops so here we are saying here we are going to use we are executing two mutations each one on two cores of my laptop and here we are generating phrases because with coms you can have post mortem analysis of the execution you can have the bug etc so here we are instantiating the runtime here as you can see we defined part of the application as a task we are using the task annotation for the solvate PC function which is a wrapper on top of the gromax binary so here the users they define the constraints for example on this task that generates the final results we are defining a binary here these blocks are wrapped around binary files so using the binary annotation the user can specify this task it takes input a file and generates an output and this is automatically done by coms so here we say which is the binary and it is up to coms to run the binary without doing any system calls directly on the user code so here there is some problem the notebook to restart there is some problem I don't know I can show you directly maybe the results of this computation just to understand what happens so here is the final result of the application we are considering that it was a very simple and small execution these two lines are not significant from the scientific point of view because here we are calculated just a small fraction of the final result which is this big feature here so this one is not significant anyway what we calculated this is the real graph of the small computation this is what has been calculated by coms part of this the most interesting part is that you can see here a lot of dependencies and these are resolved by coms some of these tasks are NTI applications that are also completely managed by coms and here is the the real final result and going back to the slides so this was an introduction to coms what you can do with coms this is our group the workflow distributed completely led by Rosabaria and this is La Barta in the computer science department of BSE so now it is time for questions here in the on your webinar control panel maybe you can pass the presentation to Rosem again yes thank you Daniele we can stay on this slide we are waiting for questions from the audience thanks for the nice discussion we have questions from Adam yes thank you I was going to go back could I go back to the slide the star SS slide that compared coms with or MPSS one I was just wondering if you could say a little bit more you may have mentioned you seem to break up a little bit just at the point you were talking about it could you say a little bit more about the difference between the kind of way that you have to program for OMP SS and the way that you have to program for pi com the comparison between the memory and the files in particular coms is quite similar and also contributes actually to openMP so openMP also is a task level programming model and coms is an implementation which is quite similar and also interpretable with openMP so here you are working with small in the sense of duration of tasks inside one node of a supercomputer for example so here you are using tasks inside one node or across nodes of a supercomputer while with coms we are dealing with tasks that first of all can have a simple files not in memory objects because we are dealing with an application that doesn't work with in-memory objects but works with files objects and also we have to distribute computation and input and output data across nodes of a cluster of a grid so it's the size of what we are going to compute sorry just to highlight the fact that also we have an implementation of coms on top of coms so you can program an application this is something which is ongoing in a European project so you can have a high level workflow described on written with coms and one of the tasks can be an ombs application for example you may want to run an ombs application that executes on GPUs for example it's written in ombs but is a part of a bigger workflow so still you can use coms to orchestrate that part of the execution because for example with coms we don't go in the GPUs we are not able to instantiate threads inside a GPU so in this case we use ombs so the difference is the granularity level of the code that's nice so what do you mean by an object in the case of pi coms then do you mean like I hear objects an object of a class for instance of a class so it's still an in-memory object but it's something bigger this object for example in the case of coms we serialize those objects we send those objects in memory so these objects are wired to the network and executed remotely okay thank you thank you Adam I was wondering if if somebody wants to try out coms do you have any links to tutorials or some other material that they can try out I don't know if I put in the end check you have different things you can download coms next actually we will release on Monday for supercomputing every year we release a new version of coms for supercomputing so we release a new version 2.4 of coms so you can download the new docker image you can download also the packages for Debian etc we have a lot of documentation and in this documentation you can find a tutorial and to execute some coms example using both the docker image or we have also a virtual appliance which you can run with the virtual box so you can follow the instructions of the tutorial and you can try on your own coms applications thanks I encourage our listeners to check out and try coms as we said it's one of the platforms that will be working extensively in the future also in barbecue cell so we look forward for its application we are already past the hour so in the interest of time we should stop here and I want to thank Daniela again and can you change to the last slide I want to announce yes thank you so in a few weeks we have the next webinar from the barbecue cell series it's on MD benchmark which is a suite for well benchmarking MD simulations and for those of our attendees who are listening to this I would encourage you to check it out it will be very useful especially for those of you running Gromax or similar MD codes so thank you all and see you next time thank you bye