RG : atom mapper landscape, current state, relationship to network planning | looking for opportunities to coordinate efforts, avoid duplication of effort RG will link slides here JC (slide 2) – Is there a concept of volume overlap that could be included? might be impossible to put ligand in such a way that it doesn’t collide with receptor RG – We’re anticipati that all the small molecules are pre-docked. So the geometries must be acceptable to the protein JC – is it a requirement that all ligands must share same core alignment? Or does it only require pairwise alignment? RG – Core doesn’t have to be constant
RG – defined some ABCs for how mapping, scorer, and network planner can look in gufe JC (slide 7) – High score is good or low score is good? MP (slide 7) – Will there be some way to have self-consistency … Are you geared toward RBFEs only, or can you score differently for different types of simulations? RG – This is why we’re envisioning having the scorer be separate from the mapper and other components. So different methods could come with different recommendations, but while there may be a default, the user will be able to change the scorer.
RG (slide 10) – Would be valuable to be able to use the Folding@Home data to assess the quality of mappings within a network; want to be able to measure rate of convergence for a given transformation, as well as compare to experiment JC – This sounds like a great thing to store - not expensive and super valuable. DD – This owuld be a funciton of how many tasks you executed for a given transformation. Let’s say you did a bunch of extensions on one transformation. The number of times you extend it and the combination of dG values could be used to determine the rate of convergence. You could do this over all tranfromations in a netowkr and that would give you a way to evaluate the atom mapper. RG – Kinda… There are other factors that would contribute. DD – True, so I guess it’s good that the model we’re pursing will allow for all of this.
JS (slide 9) – Could we store more metadata for transformations? RG – Absolutely, we can store arbitrary metadata. JC’s mic – Could also dintinguish between quality of mapping in both solvent and vacuum. JC – The solvent also has a big effect on the accuracy and so I wouldn’t be surprised if it was correlated.
JC – JS, could you set up a wiki for which information we’d like to store? RG – This sounds like a fah-alchemy logging thing. JS – I’ll talk to DD and open a fah-alchemy issue for this. IA – Here’s an existing issue that this could be added to:
JC (slide 11) – Could we add redundancy as well? So each node is involved in several transformations/cycles? JC’s mic - For the atom mapping bit itself, what validation are you going to do to ensure the mapping is valid? RG – That’s more the problem of the scorer. We’re going to test mappers as we develop them. You can usually see if things go wrong pretty early on. JC – The atom map creators … JC’sM – A good way to check this is with a cheap vaccuum transformation. Since if that doesn’t work then the condensed phase can’t work. JC – Will the protocols have an awareness of which transformations it wouldn’t support? Like, are there some atom maps that aren’t possible for certain protocols, and at which stage will these impossible mappings get filtered? RG – I guess protocol could do this, yes; could also apply a scorer JC – would it be a single scorer or a composite of scorers? BR – question regarding vacuum sims; any idea when that might fail JC mic (YTZ?) – bond breaking requirement could do this) JC – Or pathological examples that Richard showed. BR – not seeing a real ring breaking in the example that RG showed
JC – In slide 6, there’s an invalid ring break BR – Here there would be two sets of coords for each state. So there wouldn’t be a ring breaking. So this would always converge. JCM (YTZ?) – These are ring-opening and closing, which owuld cause a problem. There are two problems. One is …., but the other is how to blend FF terms - Like, whihc torsions get turned on/off, and how do they correspond. And step 3 is … Some protocols will be able to ring opening/closing, but others won’t. So some packages will allow some mappings but others wont. IA (chat) – note: we do anticipate "protocols" (as defined in the gufe framework) or engines to have their own validation routines for checking if atom mappings are just not going to work (i.e. if you used the wrong mapper for the wrong protocol) JC – How will that info propagate up to rewire the set of transformations? Like, what if this totally removes an edge, what will replace it? RG – The persistent network planner would be needed for this. JC – Could also have a communication channel between the protocol and the mapper so this would automatically get handled. RG – That would be tricky, would require the atom mappers to be aware of simulation results. JC – Willl the netowrk have a concept of “weight” for the edges? So the planner will have a concept of how easy things are? JCM (YTZ) – Do you wantiticapte supporting multiple engines? If so, they’ll define end state differently. Seems like this would be a lot of ground to cover to determing just whether the atom mapping is robust. I’d advise focusing on one engine first. Doing otherwise will lead to jank. MP – For similarity scoreing, in the paper I’m writing, people are asking about the concept of “optimal similarity scoring”, since it depends on the protocol. So you’d need to collect data on the results of running all of these on F@H to robustly find an answer.
JC – Also, YTZ, there were other things that you mentioned, like complexity around chirality inversions. YTZ – I’ll show some slides on our RDKit-based atom mapper and the difficulties it’s had. Link YTZ slides here JS (chat) – If you’re looking for more expert opinions: Lester Hedges will also be a good resource. He’s done a huge amount of work for BioSimSpace (i.e. single topology) and its atom-mapping quirks using RDKit. Happy to loop him in if needed. JCM (Joe?) – We’ve seen a lot of issues with RDKit for atom mapping. RG – We’d looked at using the RDKit callback for chiral inversions. YTZ – Chirality isn’t a local property - It depends on the environment. So that makes it complicated. SO for example RDKit may give a nonvalid MCS even though it’s not a big problem. JC – I’ve talked with MBoby and this seems to be a chicken and egg problem even in the structure prep - If we do the docking before the atom mapping, then the mapping will be biased if it considers coordinates. But if we do the docking assuming an atom map, then the most suitable atom map is implied by the core atom position overlap. DD – Don’t you also have this problem where, for a pair of ligands, we’ll do the docking trying to do core alignment, and the network connections are then determined based on possibly-different core alignments. JC – … DD – this will partially be covered by the constraint that the same chemical system have a dG=0 between its own configurations, even though the coordinates may be different. So that can be a control on pose uncertainty. JC – … MB – A naive way for how this might work for multiple structures would be to do an ensemble docking instead of a single docking. JC – But that could lead to using a different pose for each edge of the same chemical system. MB – I also tried doing an induced fit docking, but this could be problematic in a different way since it will change the receptor conf. DD – This may be a key difference between benchmarking system and a production system for e.g. ASAP. JS – In the RDKit MCS code, there’s a seed_mcs parameter, where you feed that in to guide the subsequent MCS determination. This could allow for control of the atom mappings. IA – The naive approach would be an all-to-all docking,and then pick the ones that have the highest overlap. But this would be expensive and may not lead to the best docking. MB – Schrodinger had a workflow (missing in the newest release)that would do an MCS constrained docking, then it would use of the resulting poses as a constraint for ligands that weren’t able to be docked. I’m getting a few weird results from this, but it does seem promising as a method. One downside is that this MUST be run in serial, so it may take a bit longer. JC – It may be good to NOT presuppose that you have the docked structures, but instead do the docking as part of the workflow, and score them according to their overlaps/clashes. Then you could self-consistently select the best mapping which is spatially reasonable. MB – So you’d pre-dock and store a large number of possible confs? JC – Kinda. We have a workflow that does that now, where it iterates in a way that includes spatial overlap as a consideration. RG – I hadn’t thought about extending this workflow to modify the inputs. It would seem to be an expansion in scope to include docking in this workflow.
JC – One question from Relay, which was that we changed the structures on them. IA – There was a release before 0.3. DD – There was release 0.2.1 MH – We probably need to raise the visibility of this in the readme. DD – People are probably just pulling master, and possibly using git LFS. FY – Right, we’re using git LFS. DD – Ok, we’re cleaning up the structures and doing some re-preparation, and we’re not using git LFS any more. JC – Is there a tarball with the data that used to live in the LFS? DD – The LFS stuff should still exist, but it will be a bit of a pain to get to. You’d need to clone the repo, check out the tag, and then do a git lfs pull. IA (chat) – Can we just dump a tarball on Zenodo? FY – We went back to using the original JACS and Merck sets.
FY – Is there an easier way to understand why things were removed? JC – One thing we’re working on is a changelog. We talked about this in the scope of assay conditions and xtallization info. But we can include this as well. DD – One of our goals is to ensure the previous states are accessible. But it looks like we should do a better job of documenting this.
|
Add Comment