 Okay, we're recording. Okay, so hi everyone, thanks for coming to the bespoke fit workshop. So I'm going to start with the repository. So, I think this was sent out yesterday. Information on how to clone the repository set up the environment for bespoke fit there's not kind of package yet. But this environment files should make a kind of environment for you. And there's also single file installers that Jeff's made in the releases. So hopefully you've been able to clone this make the environment and set up the notebook because we're going to do a bit of a live demo for bespoke fit. And so that's what I'm actually going to start with. I'm just going to start with running the notebook because it's going to do some fitting and data generation on the fly, and it will take a little while. So I can get this running. Just flip through all these now. And we'll go through some slides, and then we'll come back to this and catch it up and hopefully it's worked, but it's a live demo so anything could happen really. There's private stuff in there. Okay, so we'll quickly click on some slides. Yeah, well Josh pulls us up. Some folks who have used Jupyter notebooks might be used to just hitting restart and run all under the kernel manual, but there's a couple cells in this notebook which intentionally raise errors. And so if you do the restart and run all then the execution of the notebook will stop at those cells. So instead you want to you want to manually run them and especially you want to make sure you get past cell like four or five, which manually throws an error, and then make sure that you manually run all the other cells, because it's going to take about 20 or 30 minutes. Yeah, thanks for that. That's a good point. Yeah, that cell errors is right at the start. So you should see the error message and then just quickly flick through the rest and set those running and hopefully it should should start doing some fitting and we'll come back to that bit. So I'm just going to quickly go through a few slides on this booklet, how it works and why we need it. So let's start with the why. So force fields as we know allow us to type fast amounts of chemical space using the set of transferable parameters. So we've got some compromise between accuracy and transferability. So the main ways of doing this of doing the typing we can have a lot of types like we can see here for OPS three and OPS three. So this is just concentration concentrating on the torsion parameters. You can see that there's an explosion of parameter types to improve accuracy at the cost of transferability of these types. So the main ways to use a bit of a smarter typing based on chemical chemical perception, which is what open force field do, and we can see here that the number of torsion types is kept much much smaller. There's cases where this works really well. And there's probably some H cases or bits of chemical space that we haven't seen yet where this doesn't work. And the accuracy is not great, even though we can apply parameters to those modules. So what we need is a tool like force fill FF builder, I think it's called intruding it. So even though we've got this many torsion parameters in the general force field you still got FF builder on top of that to generate the spoke parameters as you go on to fill in any gaps on the fly. So what we need is a tool equivalent to this, but for open force field force fields to complement our base force fields with these extra bespoke terms. This is just an example of a molecule where this does work well where the open force field parameters transfer well into this environment so you can see in this molecule, the torsion that's been driven spin highlighted. And we've got the QM data here, which is the blue crosses, we've got our parsley force field, which is the red circles and gaff 2.11 which is the greens. So just putting the relative energy here in cake album all against the dihedral angle in degrees. You can see that we agree with the QM reference data pretty well in this case, however in some molecules, this doesn't work so well. So this is a fragment taken from the base series from the Schrodinger benchmark systems. And we can see when rotating this torsion, our potential energy surface is not great compared to the QM gaffed us a little bit better, but again, there are still some issues. So what we need is something like bespoke fits to generate bespoke torsion parameters for these molecules on the fly that can help improve disagreement between the MM surface and the QM surface. So just have a general overview of how bespoke fit works now the general framework. So we start with our input molecule which is processed by the toolkit and sanity checked. And this is then passed into bespoke fit to begin the pipeline. So that pipeline normally involves fragmentation and QM task generation, and then QM computation, collecting the results, and then passing those into false balance to actually run the fitting and get all bespoke false fields, which is what we want it. So bespoke fit can work out what reference tasks need to be done in order to fit the torsion parameters that we want to optimize. And it can use QC submit which is an interface to the QC ecosystems or QC archive and QC fractal and even QC engine. It can pass the tasks over to a QC fractal instance where it can run them all. It can be a local QC fractal server, it can be on the same machine that's running bespoke fit, it could be stood up somewhere else, and you could contact it pass it in the tasks and then query it when it's done and collect the results. The nice thing as well is it can also talk to the public QC archive if you wanted it to. In the QC archive we've got a large data set of torsion drive fragments and we can query that data set to see if is that fragment in there. If it is kind of just pull the results down and fit to those, or can I use part of the results there, and then generate anything that's missing on the fly. The query is done locally the data sets pulled down and then we check over the data set locally so the molecule isn't shared with the QC archive instance with the public instance that is so it's safe doing it that way. And the other nice thing about using QC fractal and QC engine is we get one interface to a load of different QC programs. So here I'm just showing a handful of the ones that we use quite regular. You can swap out say Si four or torch any or xdb or any of these for your favorite QM code, as long as it's supported by QC engine, you can just swap it out in the specification and run the QM using that code instead. Unless it's Gaussian Gaussian isn't supported yet. So next we're just going to look at the result of the application on this pipeline on that problematic molecule that we saw before this base fragment. So after running it through that, that pipeline we've generated the QM data, we've now fit to it using force balance and it's got our bespoke force field back. And we can now see the effect on the potential energy surface so we've got the same graph as before but now we've added in the purple stars which is the bespoke profile. That is a much closer match to the QM reference. And on the right hand side on the table, we've also compared the force fields and the RMSE era of this potential energy surface. And again, you can see there's a big improvement overall base force field, open force fields one, and against the bespoke force field which is the open FF is this force field complemented with the bespoke terms for this torsion. So it's still reusing all of the bond angle and Jones and charges from this force fields. It's just a bespoke torsion terms that have been added in to improve it. So, then we can also look how this house works over the entire base fragments set. So this is every fragment from the full base con generic series. And we can see that the general picture agrees with what we've seen that starting from open force field 1.3 and this time, which was the most recent version at the time that I did this. We get a big improvement in the average RMSE across the torsion profiles, and we also see that the average RMSE drops as well. So this is measured by starting at the QM optimized structure and then relaxing it with the mm force field, and there are slight restraints when we do this, but we can still see that there's an improvement. And that's just part of the fitting method that we use. Since this we've actually covered all of the fragments across all of the ligands in all of the jacks benchmark systems. They've all been fragmented, they've all been put on the public QC archive for everyone to use. And we've run bespoke fit across that entire data set now, which is around 480 torsion drives, I think. And we see a very similar story there, where bespoke fits improves the RMSE and RMSE and around the targeted torsion profiles. So a bit of an update on the current status of bespoke fit. You can definitely use it. It should be considered pre alpha though. And it's probably not ready for production work yet, but we're more than happy for people to start testing it, and we should have a condo forge package ready soon. So, after today, using the environment that you've got built if you want to test that out and feel free to open issues. I'm sure there'll be quite a few. So feel free to have a play around with it and give us some feedback, and then hopefully we can improve this going forward. So now just a quick glimpse into the possible future features that we're thinking about for bespoke fits at the minute we're just concentrating on the fragmentation torsion driving pipeline. But in future we could fit to say like the bonds the angles and product torsions and charges. Anything that we do in the general open force field fitting, we can do in bespoke fit as bespoke fit can now be used to fit the general force fields and say it was actually the first force field fit using bespoke fit as well. So we do have the ability to do general force fields but that's a little bit outside the scope of this bit. So in terms of validation, we're looking at doing free energy calculations, starting with the T like a two Schrodinger system since we've got all the torsion drives now on the public qt archive and makes sense to start with those because that's the most expensive bit of the pipeline is generating the QC data. And maybe also expanding the benchmark work that we've been doing. So in last week's workshop, we learned about the open FF benchmark effort. So another possibility is to expand that and use a bespoke fit force field and see what happens with the results there. Yeah, so that's all of the slides. Yeah, I just want to say thanks to everyone that's helped so far so John said, Jeff, David, John, then he called and the rest of the open force field team so now I'm pretty much over to the notebook. There wasn't that many slides. Is there any questions before we move over. I have a quick question. Do you get. Are you generating new torsion types, or are you just refitting the types that you already have. Yeah, so there's the option to do both in bespoke fit, you can choose to generate a new types on the fly, or you can just refine predefined types in the force field. Okay, thank you. Yeah, no problem. Probably if you did the latter you might have to worry about messing other things up. If you read refining types or redefining types, I'm guessing. Yeah, that's what I was concerned about. I would recommend to not do a general file and just local one for. So the first option. Yeah, by default it will generate the bespoke types for you. Josh you want to comment on what happens. If you want to like apply this across a ligand series like a congenital series or something. Yeah, I can do so. That series that we looked at the base one. Yeah, maybe that's not the best example because it doesn't really have a common core. The TYK to series did have a common core. So when you do the fragmentation across this country next to you see one core keeps popping out. And bespoke it will recognize this little only computer QM data for this call once, and then it will reuse it between the ligands. The smurfs parameters that made for this common core are actually transferable as well so once they fit the bespoke smurfs for the common core transferable between the series. So you wouldn't have to refit that bit you would just refit any extra substitutions that you put on the fragment that says, these are important, and you should rotate these bonds basically and fit those. Yeah, I think. Yeah I think one important thing to mention with that. The PC archive set that you were showing is that in some sense what would be great would be if we could ship bespoke fit with a bunch of pre run QM scans for common cores. And so we don't have that yet, but we do have a good start towards that which is the fragmented set that Josh was just sewing. And he kind of made a point to this but I want to reemphasize it. People at companies are working with internal molecules and they pull down an entire data set to kind of seed their QM data for for doing bespoke fitting. No information about the molecules that they have internally would be leaked. Effectively, one could pull down this whole portion drive data set of pre computed fragments without identifying what portions of that data set are going to be used later. So like I said right now we have sort of sparse version of this data set online, but in the future we could look into pre computing, sort of a denser data set of common scaffolds and common cores that people could be pulling down. So to add to that one of the features that would next one in bespoke fit is to then store the smirks parameters and the final optimized parameters for those fragments. So those could be reused at the minute if users want to reuse them they've got to keep hold of their force field files and try them out, basically. So it would be quite nice in the future to have a database of those built up and these are the fragments that have already fit. Here's the parameters what's missing and only fit what is missing. But yeah, that's that's still the come. Should we give the notebook ago. Yeah, let's do it. Maybe for the, for the folks who joined during the talk maybe repeat your instructions from the beginning. Okay, so I want to follow along with you. Yeah, good plan. So we've got the bespoke fit workshop repo set up here and I think the links have been set out. So this is what we're going to be using today and there's an environment file here to build the condor environment that you'll need. So everything else is here and this the workshop notebook. And if you're using a single file install is the release is here if you want to download those and install them. So all I've done so far is start up the notebook. I flip through just to all of the cells and just to get those running so we're doing a live fitting and live data generation using QC fractal. And it will take a little while. So hopefully they're far enough ahead and we won't catch up to them too fast. So during this live bit, the hope is that we're going to build and configure some general bespoke for optimization workflows and see how we can save those and reuse them later. Build molecules specific optimization schemas from this general fit and pipeline. So we're going to try and load in some QC archive pre computed data. So that's the data set that Jeff talked about. And then we're going to let bespoke fit work out what it can reuse. So it's going to loop over that full data set. It's going to look for molecules that it's trying to fit. And it's going to make sure that those torsions were driven in those molecules and try and reuse that data. So we're going to try and optimize those bespoke torsion terms. Have a look at some of the results on false balance and then try and generate some reference data locally using XTB just in the sake of time. Using a local QC factor QC fractal service. So I'm just going to start off by importing everything. And then we're going to look at building the general workflow. In this general fit you have a general workflow pipeline that describes each stage of the workflow and all of the settings that will be used. And this general workflow is then applied to each molecule that passes through it. So by default it's set up to fragment molecules and run torsion drives, but we're going to start off with an empty workflow and then build it up piece by piece just to see how the options work. So what we need is the actual optimizer. So in that case that's false balance that's the only one supported so far, but we should be able to add some more in the future. So we start off at the force balance schema objects, and we can have a look at what's inside so we can see all of the attributes here these are related to force balance fitting options. So if anyone's ever made an optimized in file for force balance you should recognize this list of terms and yeah there's absolutely tons of options for force balance. And sometimes it's not obvious what an acceptable option is so in, and for the sake of this the penalty type here it's L2 by default, but it might not be obvious what are the other options available apart from L2. So these schemas are all based on pedantic, which allows us to define the schema, define valid options for the schema as well, and for it to validate itself on the fly as it's been assigned parameters. So if we ask the force balance schema project for its schema, we then get this nice print out of each term, it's got a description, it's got its default value, and it tells us it's type. So that is a number that definitely makes sense. We come to penalty type. It tells us that the available strings are L1 and L2. So it's self defined, and all of the options are actually contained in that object. So we can look at the validation so let's assign L3 just as something random that is definitely wrong, and we see we get an error back straight away, telling us that that is not possible. You have to choose from L1 and L2. So the hope is by using pedantic we can get all the validation issues out of the way before we even run the workflow. The hope is when we run the workflow, none of these errors will pop up. The only issues that we should see will probably be related to like QM jobs failing. We don't want to set this off, wait in a couple of hours and then realize the force balance fit didn't work just because we made a type on one of the input lines. All of that should be avoided using this schema based workflow. So now we can set it to L1, that's the one we want to use, and now we can set up the bespoke workflow factory. So if you notice here I'm setting everything to none and empty lists just to get rid of all of the defaults, because it comes like I was saying pre pre packed with the torsion drive fit and workflow. So, some of the options in the general workflow are expand torsion terms. So when the torsions come from the open force field, they might have just a K2 defined or just a K3 defined where that makes sense. So in some cases you might not get a very good fit using this you might need to expand it, maybe if the K term is wrong. So expand the torsion terms will take the open force field base and expand it out so it has a K1 through four, and it'll just set those to some small values which can be optimized. We need to choose a fragmentation engine. It's going to generate the bespoke terms by default so that's bespoke Smurx patterns for this molecule and fragment. So we can also choose our initial base force fields that we want to start with and fit on top. Here's all of our optimizer settings and then there's a few other categories print the sentence targets smurx and target templates. So bespoke for currently makes extensive use of open force or fragmented package which was just open I based and is now amber tools base as well so it is open source and can be used with open source software. Here we're using the WBO fragmented. We are just leaving the base sentence because those are the same sentence that we use to fragment the QC archive molecules, and we want to make sure that we get the same ones back so we can reuse that data. So we're now in the workflow just passing our fragmentation engine, and next we need the target template, the target template just tells force balance what it's actually going to be fitting against kind of defining the objective function. So in this case we're going to use the torsion profile target schema. It has a couple of options specific to itself, and it will tell bespoke fit that it needs to generate tasks related to torsion drives, and it also needs to then fit the parameters to these torsion drives. So we just start off that schema we're going to use the default sentence again, and we're just going to pass that into the target templates. So you notice it can take a list of different targets, and there's different ones available. So we have so far optimized geometry fitting and Hessian fitting those aren't as tested though, but you could you could supply all of those while you're doing these optimizations, while you're optimizing the parameters and it'll fit to all of those targets. And the last two in the workflow describe which general types of parameters such as bonds or angles should be targeted, and then which component of the parameter should be optimized. For example, you would have the bond parameters but then you might only want to fit the bond force constants, and that allows us to distinguish between the two. So we tell it the target smokes in this case we want to hit proper torsions and we use proper torsion sentence, which only allow for us to fit the key values in this target. So it also has the prior, and this is just related to force balance. And here we don't support fitting of the phase, we only support fitting of the force constants for the torsions. So now we can export this workflow to Jason or Yaml file, and we can reuse that later. So if I go through. We can see how it's been serialized down, and we can keep that around as our general fit workflow for say a project and we just load this in every time run the molecules through it. And we know exactly the same protocol has been applied to every molecule that it sees. So now we can build molecule specific schema. So I'm going to start off with this base ligand data set and load that into the open forceful toolkit. And I'm just picking this molecule that's in there. So we can now build that schema by passing in the molecule into the workflow and asking it to build an optimization schema from a single molecule. So it's an option to pass in a list of molecules as well, and it will build a list of optimization schemas. We can also pass in results directly from QC archive, and it will build schemas for the, the torsion drives in QC archive. So the first job that is trying to do is fragment the molecule. We're going to create two fragments here. So it's fragmented around the three rotatable bonds, which is this one, this one, and this one, and that's produced two different fragments. And then during this stage, the bespoke smurfs patterns have also been made. And we can check that those bespoke smurfs patterns hit the right atoms. We can also check that in the fragment, they're hitting this torsion, these two torsions, and then in the parent, they're hitting these two torsions, which is the same one. And they don't hit the other fragment at all. So it's bespoke to this fragment, and that transfers well to the parent, and that should work well during fitting. And it's definitely not being misapplied to anything else in the system. Josh, I noticed that cell 12 took a while to run. Can you explain what's going on behind the scenes there? Yeah, so this is the fragmentation. So this is using amber tools. And this is our, well, I think it's Simon's implementation of fragmented using amber tools rather than open eye. So this is generating a lot of compromise. It's been doing a lot of am one calculations behind the scenes. And then the fiber bond orders, and it's using that to fragment the molecule. So in these fragments, if you're not familiar with fragmented, these are generated to ensure that the fiber bond order in this rotatable bond is the same in the fragment as it is in the parent. So this requires hundreds of WBO calculations behind the same. So it does take a little while to get the fragments out. So comment on what those warnings are. I know you're just scrolling past them. Yeah, it's just so in the distance matrix when you work it out, you should have zeros along the diagonal. But due to position issues you get non zero values and it tries to take a square root of a negative number. So yeah, we just need to clean that up. Okay, thank you. We can also check the QC specification that's going to be used to generate this QC data. So by default because we didn't actually supply any of this into the general workflow. It will use the standard open FF specification, which is defined here so that's using a side for this basis, and this method. But this is fully customizable as well. So here you can look at loading data from QC archive. So here we're just going to connect to the public QC archive but you can imagine this could be a local QC archive as well. Just connect into the public one and listen all of the portion drive data sets, you can see the open FF have provided quite a few. Lots of these have been used in fitting the mainland force fields and benchmarking and testing. We've got quite a few on there, but the one that we're interested in is this one. So this is one that I put together a while ago with all of these Schrodinger jacks ligands that have been fragmented. So we can use QC submit, which is our interface of QC ecosystem to pull down this entire portion drive collection from that public QC archive using default spec because that's the one we're interested in and that's the one computed at the open FF default. So if we pull that down and see that there's 368 unique molecules in there with 481 torsion drives. So these are all 1D scans and some molecules have multiple rotatable bonds. Like the base fragment that we're looking at here. What we can then do is pull down the actual records from QC archive. So the QC submit object is just a wrapper around the data set with references to the IDs in QC archive. What we can do is actually pull down the records and QC submit will manipulate them into a format that can be used with the spoke fit. It'll also produce an open FF molecule objects with the conformers from the torsion drive attached to it. So if you wanted to view the torsion drive or if you wanted to then write it out to a different format like SDF or PDB anything provided. It's supported so by open FF fields, you could do that through the molecule. So this is the raw QC archive torsion drive result objects, you can see the dihedral angle defined here. Here's the raw energy in heart trees. We've also got other information like the initial molecules provided to run this portion drive. In QC archive every molecule has a separate confirmation. So these are the same topology graph but different conformers that have been used to seed the torsion drive. You can also see the dihedral angle that was rotated and the grid spacing between them. So these are all just references to the objects in QC archive. So this is just a molecule with that ID. And then see all of the keyword settings that we use. So these are geometric settings within got provenance information and again we can double check that we definitely use the right spec to compute this data. And then we can also look at the torsion molecule. So this is just the first one from that data set just a random molecule and all of the conformers from that have been attached. Not in order, however, that possibly needs fixing. But yeah, they're all attached to there. So this book can now take this full data set, it can look through it, and then it can determine what data it can reuse and what it can't. So that's the schema that we made earlier. Are you ready for fitting? It's not ready for fitting. We can then have a quick look at the just the first 12 torsion drives that are in the data set. And if you notice here, the rotatable bond is highlighted so the torsion that was driven has been highlighted. But none of these molecules are the ones that we're interested in. These are not the base ones, but they are definitely in that data set somewhere. So then what we can do is provide that list of records and molecules. We can send that to the schema. It'll search through them. And once it finds all the data that it needs, it'll stop. And then we can ask it again, is it ready for fitting? And this time it's true. So it's managed to find the torsion drives that it needed. So that was. So that's a torsion drive for this bond and this bond for this fragment and the torsion drive for this one for this fragment. It's managed to find all of that in the data set. It's pulled it all out and then saved it into the schema. So now we can actually optimize the bespoke parameters. So if it gives us two options, we can either set up the force balance optimization job for us to run later. So it could set up all of the files for us. And then we could submit this to a current system or we could come back to it and run it later. Or we can use the executor class in bespoke fate to automatically run the optimization for us and collect the results. It will also generate data on the fly. If there's any missing, but if it determines that there's nothing missing, it won't set up a QC Frapple instance and it will just do the fitting for us. So here we're going to use the executor. So we just started up. We then wait for the result and we pass in our schema. So then goes off stats generate and target directories for false balance runs false balance. And then once it's done, it kills all of the workers that were set up and returns the result. So if this big didn't actually work, there are some results included that have fit previously. So you can just uncomment this line, deserialize the results and then continue with the rest of the notebook. So, once that's complete in the background, that's done the false balance optimization. So if I go over to this bit, we can see that this new folders being made bespoke tasks zero. And in that there's all of the false balance setup, and that actually ran the false balance optimization. So now we can have a look at some of the results from that. And here we can see the plots that are produced by false balance during fitting. So the blue line here is the QM reference data, the orange is our MM current data. And the green is the fitted torsion parameters, and the green is our initial starting torsion parameters. So to see during the fit, we've improved the potential energy service of one of the dihedral's. And we also have a look at the difference in the parameters as well. So in the result bespoke fit has extracted the final parameters for the bespoke smoke patterns, and we can look at the before and after, and we can use these patterns to build a force field and run dynamics or use it with the rest of the open force field stack, it works in exactly the same way. So here I'm just extracting the before and after in the parameters. So here we have the result object which contains the input schema as well for provenance so it knows exactly what was done and to produce that result schema. We can then compare all of these values and look at the change for each one. For a lot of these values, they start at some really small term. So we don't see them move much. These are all of the extra values that bespoke fit adds in just to make sure that we're not limiting it by not expanding the key terms. And in most cases, a lot of these are redundant. So if the after value is very close to this before value and it was added to and we can actually drop them out of the force field because they clearly weren't needed. And then we can also plot the results and look at the change. So here I'm going to be plotting significant changes, I think bigger than, bigger than one time sender the minus three K Kalpamol. So if any of the parameters did change by more than that, they're plotted on here and we can see how the optimization has changed those parameters. So I'm just plotting here the force constant along the bottom in K Kalpamol, and the smirks parameters. So what we can see for smirks zero, it's got K one three to four for smirks one one three to four, and that's just repeated for each of the smirks patterns that have been made. So we can now re parameterize our molecule using our final force fields. So from the result, I'm just going to grab the final force fields, going to set a drop out value. So I'll drop out any terms at any terms with absolute value less than this because the probabilities were introduced by bespoke fit, and they're probably not needed. So now, if we label our molecule using this force field, we can see that we extract the torsion terms if we scroll down we see normal open force fields parameters. And then we see some very large smirks terms that have been introduced. So these are the bespoke ones that were generated specifically for that fragment. And we can see those have been correctly typed onto the molecule. Okay, so the last bit. So now that we've fit all of the fragments. Now we're going to try and do the QC data generation on the fly. So just for the sake of time I'm using XTB to run these jobs, just to make sure that it was fast. But it should work like I was saying earlier for any QC program. So imagine swapping this out for any or CIFOR or anything else. So this is how we define our QC specifications before we run bespoke with it. So we take this QC spec schema and we supply its method its basis program spec name and a description. And because it's based on dynamic again this is all validated ahead of time as much as possible. So it'll check for the program XTB. Do I definitely have a method with this name. And does this basis make sense for this method. So it's validated before you get to run time before you get an error back from QC engine saying that it doesn't work. So it's valid as much as possible. So by default, like I was saying earlier, we use the QC, we use the OpenFF QC spec. But now we're going to change that out to use our custom spec, which is this XTB one. It's actually defined in the target template. So when the targets generate in its torsion drive reference data, and it's tasks. It also puts into the schema what spec those should be computed at. So now for the torsion profile target schema, under the reference data section, we're going to provide bespoke QC data with our specification. So we're just going to add in that target into a new bespoke for work factory. So that's just this XTB workflow and then we'll have a look at it. So we can see. So this is just the default one. I'm going to see that the settings are the same as what we've configured earlier. It's got the fragmentation engine being WBO fragmented. The optimizer of the settings there, the parameter settings have already been defined, the target smirks, the target template with the only difference being now that our reference data has a new QC spec stored in it. So what we can now do is take a molecule and put that through our new workflow and try and generate the reference data for it. So I've picked a small molecule here. And by default this won't actually work in bespoke fit because fragment it will only fragment around rotatable bonds that are not terminal bonds. And so this bond here wouldn't actually picked up by fragment there, but we can overwrite this behavior by telling the fragmentation engine this is the target bond smarts that we want to use. So it will highlight this bond and it will work. So now, if we pass in the molecule we get the STB schema back. So this hasn't been fragmented it will just be the same molecule because we can't really make this any smaller. And it will have targeted that rotatable bond. And what we need to do now is set up how we're going to run the calculations. For example, I'm just making a local QC fractal snowflake server that's this fractal snowflake handler, and that's just running in the Jupyter notebook in the background. So we can start up the snowflake server, wrap it with a client, and then it'll give us information about where the server has been set up. So this can then be passed into the executor under the client. So we pass the schema again on to client. And as long as you have permission to run tasks on this server, which we do because we've just made it here. Then it, it will submit any required QC tasks into that server to be computed. So then we get some read out about running tasks. So what the executor then start to do is check what reference data is missing. And then we get all of those fitting tasks, pass them off to the QC fractal server. It will then keep querying the QC fractal server periodically checking that they're done if they're not done. What's the error. If it's an error that it knows how to deal with it will try and restart it and correct it. If it's not, it will just remove it from the queue and say that it'll give you a warning. This is a rid. And here's the error message. And then it will save that to a JSON file that you can look at. And once the calculation is finished, though, it will collect the results and then start the force balance fitting tasks by itself automatically. So I'll run it through the rest of the pipeline while he executes running. And then once it's finished, it'll kill all the workers and it'll just return the result. The result is also periodically. So while this is executing this does block. This is periodically saved to a JSON file. So if anything does go wrong, there should be some checkpoint of it saved to the local file. So now we can just connect to that client and just see what it actually did on that QC fractal server. So if I list all of the connection, all the collections on this client that we just made, we can see that there's a new torsion drive data set. So what this torsion drive data set and pull out the first index, we can see that there was a successful torsion drive using the xdb. So what we can now do is use that data to then do the fitting. And that's what it did. It did that force bonds fit. And we can see here the green. This time is our starting force field oranges our current or final result and blues our QM data we're trying to fit to. So we've improved the fit to the xdb server surface. And yet if that didn't work, again, there's a serialized result in the repo so you can just be serialized it and start from there to analyze the results. And again, we can just collect all of the initial and final smirks patterns and the change in parameters we can have another look at that, and we can plot those just to see what happened during the optimization. And yeah, that's that's pretty much everything so that's just your typical application of bespoke fit as it currently works. I think it's definitely scope for improvements and quality of life improvements, but yeah, that's that's it for now. So, is there anything that was unclear, is there anything I should go over again. Thanks Josh I think that this was, this was really excellent and I like all the work that you put into the notebook. So at this point, maybe we want to open it up to a brief Q&A session and then we can. We can help debug people who are encountering issues running this locally or take kind of rolling questions for a while as people interact with this notebook and try changing settings or looking closer at things. And at this stage it would be good to ask if anyone has general questions about either the talk or the presentation of this notebook. This is, this is Thomas, I'm just a little bit. I'm not sure if I understood that correctly how do I connect to my HPC environment where buyers. So I'm curious, is there a way that I basically throw that out my Q&A calculations to Slurm somehow or. So currently no, unless you're using QC fractal, and you're putting your managers in Slurm, currently no, there isn't a way to do that. But we have been working on adding local computations through QC engine. So yeah, you will be able to do that in the future. Okay, because this is something for the benchmark really nicely. So this is, as I believe the only way I can get my HPC resources into this. Yeah, that makes sense. Yeah. You know that people have trouble sometimes with QC fractals. So yeah, there will be local QC engine support soon. Okay, very good. So Josh with QC engine support, would people then be, I'm trying to think of how we're running the benchmarking we have some people who are dispatching large number of Slurm jobs that each are like Q jobs that each have a couple of molecules that they're going to work on but then we do have a few people with a single QC archive instance, or a single QC fractal instance that's talking to a lot of workers on HPC. So it sounds like you're focused more. It sounds like the first thing we would get would be that first type, where there's a bunch of separate jobs that only know about a few molecules each. Is that right? Yeah, that's right. Yeah, it would basically work exactly like the benchmark stuff. So currently we've got that support for the QC fractal setup. Yeah, the spoke fits kind of just listening and communicating with QC fractal, which is already set up on like a HPC. And then the other option would be to submit either individual schemas or lists of schemas like collections of them separately is as jobs. Cool. Thanks. Okay, well great. So I might suggest if there aren't any other questions that maybe we take a short break. And then we come back and sort of have an open interactive session as people try different things on their local machines. We can stay around maybe for another half hour and provide support or answers for questions that pop up. How does that sound Josh? Yeah, it's a good idea. Okay, great. So maybe let's feel free to keep playing with the notebook. Let's maybe take a break until 8 to till the hour. So whatever hour it is 58 in your local time zone. And then we'll be back to take questions or help people customize the notebook as it runs.