 Our next speaker is David Dotson here to talk about alchemy scale. Awesome. Thank you, Jeff. Thanks everyone for coming. Yes, so I'm going to speak about this project that we've been running since about March or April of last year so 2022. We've had a working group comprising open ff open FV and folks from the cadera lab. It's been working on this, practically every week for the last year so the fruit of that labor is alchemy scale. So this is an open source high throughput chemical free energies and execution system for use with HPC cloud bare metal and folding up. Oh, and I should introduce myself. I'm David Dotson. I'm an independent consultants. I work with OMSF and cadera lab. So that's, this has been one of those major efforts for the last year. Thank you. So, this project was born out of a shared need by several stakeholders. So, a discovery, which, which the cadera lab is a part needed to advance the COVID moonshot infrastructure into the ASAP discovery infrastructure so ASAP discoveries is this open science drug discovery platform, particular for pandemic potential virus targets. And basically they the current infrastructure that was built from the COVID moonshot just wouldn't scale to the speed of iteration that ASAP discovery was going to be open force field we had we heard Lily alluded to this earlier that a benchmarking apparatus for protein liquid free energy calculations, both open amendment grow max was desirable basically decreasing the cycle time of iteration from a new idea for force field to testing it to new force field. So, being able to to rapidly test new ideas and then rapidly benchmark advancements. And open free energy. Would have liked to have a platform for assessing and evolving limitations of binding free energy methods, different atom mapping approaches different execution strategies basically everything within their remit system like this would be a huge game. I just want to give the context where I'll kind of scale sits. So the open the ecosystem is Richard pointed out. It gives a lot of workflow flexibility to users. So, in broad strokes what we're trying to do at all, at all times, we're doing free energy calculations is you know we're defining the sets of systems that we're interested in getting free energy differences between. So, we're doing drug discovery we're trying a lot of different ligands for given protein target we're building these are chemical networks. Then we're executing those networks we might be using a commercial solution for that you might be using something that we built internally, you know, something that may be a bunch of scripts that we threw together. And we've been using years that could be our execution engine. We also have tools for analysis taking what comes out of execution with out of the expensive part. In order to then iterate on this process do the whole thing again, again and again. So reducing that cycle time is a key. And the tooling that open it open a fee draws from so if he is a is a intended to be kind of a top level package for users, but it draws from these these other packages listed here like to be a low map photograph. These sit at the defining stage how we define the work we want to do. As far as execution engines go open a few does expose some ability to execute. I'll be talking about alchemy scale here that sits in the execute column. And then for analysis we have lots of other tools, and perhaps many of them not mentioned here, but these are the ones that are used within open a field. So, you might ask, why would we need different things in this execute column. Well, honestly, different tools are more or less appropriate depending on what kind of infrastructure you have access to. What your constraints are within your organization. Basically, there's not a one size fits all solution for execution. And we'll be talking about alchemy scale here. So, what is alchemy scale. Well, it was in the title. Longer definition is, it's a service oriented execution system for all chemical networks. These are chemical networks as defined by movie suitable utilizing multiple compute resources so HPC clusters, individual hosts pulling it on work servers is something that you can do as well to support large campaigns that require high throughput. So, if you just want to run a few edges, alchemy scale is probably not your choice. If you want to run thousands of edges and many many many networks, perhaps across multiple teams in your organization that alchemy scale is appropriate. And you can use all of these resources or different variations of resources and wants with a single instance will see how that works. You can use the same core data model, as all you need to use the goofy. It's deployable at least a single server deployment is deployable in a few steps with Docker compose us. Architecturally, it uses a Neo4j graph database that serves as a central stage form. And this uses, it also uses AWS three for the object stores to hold on to result. The fat stuff that comes back from calculations. User access is provided via the icon client. This is an HTTP client. It talks to API services that broker interactions with the state and the object stores. So it's a standard kind of web services architecture. These compute services that actually do that perform these protocols for the movie model, these can be deployed on resources also are like, so that you can see closer to the posts, and they will draw tasks from the API services, execute them and then push the results back. And we're now in production. We've been using the system now for several weeks. The first deployment of up in a scale is now in place it's actually a shared deployment my open FB open FF ASAP discovery and actually their lab by extension. And so this is delivering results for us your fun elevator, one of the highlight you went ahead and ran a mind benchmark of open FF 2.1 against 2.0 to MCL one from been into a 38. And just as a scientific side, because open FF 2.1 was just a valence reset. We weren't expecting this to really change what we get for free energy calculations against 2.0. So what we expected to see was basically the same results that gets both force fields. We've largely seen that here. If we saw something different, we'd be concerned. We do have some allies that we're now into but that's speaks to the power of this approach is that your phone was very easily able to just declare what he wanted run, submit it to the instance, and pull results back and then iterate. So I'll talk a bit about how it actually works. We already talked about some of the components but now this bit of a diagram. So, this is your user workstation, the user, you can define a chemical that works. Here's the client. So as I said, users interact with an outcome skill deployment via the clients. So this is, you can define an identical network using open FF 2.0. It's underlined. It's a 50 data model. It's underlined. That whole network that you define can be submitted to through the clients, and that network is that represented in the state store. So it's fully represented in the O4J and the graph data. So you can choose, you as a user can then create an action tasks for the transformations in the network. So you can choose, maybe you want to run a few networks to begin with, or a few transformations to begin with. Maybe you want to run them all. You can kind of do whatever you want to do. And these are then picked up via a weighted random selection by compute services that are running on remote resources. So if you have access again to HPC clusters, make multiple maybe Kubernetes cluster container, container orchestrator that's running these basically whatever your resources are, you can hook them up to your FF 2.0. When these compute services push results, or when they finish, they push the results back to the object store. So again, the FF 2.0 lives in an object store. In this case, it's three. Each one has a reference in state store, but as a user, you're living on this land. Basically all you have to do is push things, define your network, action tasks, and then pull your results as they become available. So all of that machinery down here is largely abstracted from. Oh, sorry. So, so that's the basic workflow but I wanted to point out a few things that alchemy skill allows are really enables programmatic and iteration or iterative evaluation of chemical networks. So, let's say you define an initial network. So this is something you'd like to calculate. So if you want to do a big small and submitted the action tasks to get results back, you decide you want to expand it. You can go ahead and do that. And if you, let's say this network shares a lot of chemical systems these red dots and connections with the previous one. The network takes advantage of the existing results in the database. It doesn't have to start from zero. It literally is just a delta on the existing network. And you can go further. Let's say you decided later you just want to trim your network so you remove some, some nodes and transformations you've calculated previously. It's not a database but you're just submitting a network that is a trimmed or trimmed and expanded version of a previous one. Again, it will share results for transformations that are in common. So, this capability of being able to take advantage of existing results for transformation that are already present really does enable rapid iteration and efficient compute use you don't have to start from zero every time. You can do smaller deltas and iterate or very large. And I'll tell you, it enables, it really is a multi board multi user system. So there's authentication built in this is intended to be exposed to the internet it is a web service. And so, let's say you have to network to submit it. So the network has this concept of scope, and it serves two distinct purposes I'm going to illustrate here. Let's say we submitted these networks to the scope is the organization open. It's the campaign benchmark, and it's the projects open up to zero these networks because they share certain chemical systems and certain transformations. It allows you to be able to take advantage of the same sets of results in the database they're represented as the same objects, because they sit in the same scope. By contrast, so you have shared my search results here. By contrast, this network, which does have elements in common piece over here. It sits within a different scope. Let's say submitted by someone who works for a discovery. The ASAP work in this campaign, this project. This will have its own distinct transformations despite them being identical something that exists in the database. So there's a domain boundaries is how we partition data and users in alchemist scale. So, the implications of this is that users with this access to the same scopes can directly collaborate in those scopes. The access to disjoint sense of scopes can't see or interfere each other's work. So it really does allow you to, to work together if you'd like, so you can see the same things work on the same pieces, but if you need to silo work, let's say, you know, you're a discovery company and you need to partition or put firewalls between certain teams, you don't necessarily need a different alchemist scale instance for each one you could use the same one you just have to set different scopes scope assets. So, for example, if I'm here from over there. He has access to the open B star star scope so you can get anything within the fee, create whatever you want to look in that, as long as it matches this pattern. And then let's say we also have Mike Henry who's not here and then again got to somewhere right here. They have asked, like, my Henry has asked these two here. And then he has access to just the ASAP scope. Yeah, it might collaborate over here. Mike and your phone can collaborate over here. But your phone can't see, can't even see the exact stuff, and yet they can't even see the open FV stuff. And so the same system supports both sets of users both organizations, even. Mike, who has access to both these skills. So it still allows you to very flexibly, you know, if you've got some people who are shared across organizations, they're able to to see what they get access to what they need. So release 0.1.2 is now available. Alchemist scale isn't fully open source province. It's open development here. So the version zero one X series, this is the MVP version of Alchemist scale. There are rough edges. There are performance bottlenecks. You can consider this unoptimized version, right. We were aiming for feature completeness at least for the initial MVP, but necessarily performance, and it does have insufficient documentation. But it said 012 is the current after this. And 013 release is actually based with books on some initial books and some of them fixes some critical features across groups. So our initial users of this deployment spotted lots of things that, you know, they would like changed. We're trying to rapidly respond to that, get some fixes out a new release deploy, and then they can take advantage. I just want to say where we're going. We're making effort for critical requirements and all the projects that all chemist skill either uses or touches or impacts via that working group we meet every week we operate in two week sprints through some donated effort from stakeholders involved. This whole system would not have been possible without that working group. So it's, it's been a pleasure to say absolutely critical to the process. And we're continuing to go. So many major releases will focus on in particular zero to focus on docs and initial user feedback so filling in our documentation gap. We ask real users, and then zero three beyond that will focus on new features to optimizations and then some targeted refactors things that will take some learnings and then pull the guts out of it, put it back together in different ways. I should say the fully informed service that will allow us to take advantage of access scale compute the ASAP, how chemist skill deployment will be working on that over the coming months. This will really enable us to take advantage of a massive amount of compute. I should say that the height of COVID, the COVID, or the folding at home network comprised about 1.5 x flux it was bigger than the top 10 supercomputers combined. So if someone has a great figure of it would have been I think $6.8 billion per year of AWS compute with how big of a cluster that is so if you're being able to have access to to that amount of potential compute will really accelerate MSS efforts and ASAP discoveries open science open So, I'll come as I do want to give credit on him scale was drawing from a long line of prior art. We are standing on the shoulders giants get a lot of architectural inspiration, that's fireworks QC practical and spoken about the spoke bit. We also got a lot of stated desires on the front from stakeholders, natural users via the user stories they provided. If you're interested in this system, and you've got a problem you'd like it to be able to solve. Feel free to make a user story on the issue tracker. I see all of these. I tagged them. I'm going to try to see if if our chemo skills a good fit for that problem. And if it isn't, we want to know. And to reiterate a single deployed on him a school instance is now enabling continuous and presumably it can enable quite a bit more that we haven't even thought about. And I want to put this out there if you're interested in deploying and using our scale. It's fully open source. We do well feedback on how easy it is to deploy how easy it is to use. If you want direct home with deployment use or if you'd like to evaluate it for suitability in your own environment. Let's chat. I'm here all meeting. We can assess that. And we do want our chemo scale to be a sustainable projects. We don't want to be some one off thing that improves rapidly over time. And we do believe that it's adoption drive. It can help drive sustaining moments in the system logic future. And in order to realize that future early adopters are critical. So we welcome you welcome. We've done a lot of work. These are the folks that have been involved in the working group of the last year. If I missed you, I'm so sorry. The intended course. There are many that a lot of work at this building on top of the standard for that. So grateful for this community, the free energy workshop community that we just attended the last few days. All of this is built upon it. Thank you for your questions. It's not a question, but I just want to say that this is what you're doing. This is where production is in and industrializing the infrastructure. This has the potential to see lots of benefits to the much wider business. So are you talking about encryption at rest encryption transit. So we do I mean alter. Yeah, sorry. So Julia asked about encryption. You know, so we talked about separation of data like in different users see each other's data via scopes, but is the data encrypted at rest is it encrypted in transit. Communication between say the clients and the API services is encrypted via gts so it's us. So that's in transit, we don't encrypt anything at rest so anything that's landed on the object store is not currently encrypted we could have that. It just means there's keys on the API services and that could be done if that's of interest. Is that is that something that you would find is critical. I think that would be fairly easy to add if encryption at rest is desired. Now encryption in the database itself in Neo4j can be done but it kind of starts to make it harder to use. It makes the database model more difficult. Some things could be. Yeah, we can. So we currently do approach the permissions problem via scopes mechanism so and it's the API services that that enforce it. So even if a user acts their client, it doesn't change anything. Yes, we have a running instance. Oh, sorry. The question was, have we actually deployed an alchemist scale instance. Yes, we have a running instance it's running for several weeks now. And it's in service to open ff, open FV, a set discovery, it's delivered the results that I displayed early early on. Yep. What is it cost free energy. So the question was, what is it cost to run a free energy campaign on on AWS in terms of dollars. So we're not actually with this instance we're not running any of the GPU calculations on AWS. Our server, so our all chemist scale server instance, like go back to the architecture. Everything that was in the green box. Anyway, the, the alchemist scale server is running on AWS, and we use as three, but all of the compute services are running currently on my lack, which is an HPC cluster, or Pacific research platform which is a Kubernetes cluster. So, we're currently load balancing across two very different cluster architectures to deliver free energy calculations for that deploy instance. Does that answer your question. Okay. Let's go ahead and thank our speaker David Johnson. And we're just about to be able to bring for lunch, I think, but I just wanted to take a minute to thank all the people will distribute. I wanted to take a minute now we're all together to thank MSF for putting this on and the funding and for this part of the chance I've heard an issue. So, and especially MSF at the board level was just Carmen on Intel just very recently when Mark joined so a big hand for MSF. And as you now know, there's several projects that own us up that have their own staff, but as an org it was literally only one person and only enough money to pay that one person till various. So thanks again, and we're really glad. I know MSF and all of us are really glad to help. Anything else before lunch. Okay, thank you.