On Wed, 2021-09-01 at 16:55 -0700, Seth Harris wrote: > Hi all, Hi Seth,
> I am increasingly dealing with large macrocycles or cyclized peptides that > include unnatural amino acids or > modifications. Early on my approach was to treat most of it as the native > peptide scaffold, then add a few custom > 'LINK' records to capture covalent bonds to some non-native moiety, and that > moiety would be defined as we do for > small molecule synthetic ligands. Advantage was that it was efficient for > refinement of the conventional amino acid > scaffold. Disadvantage, a bit cumbersome and I do find that while the > covalently bonded attachment point is > reasonable, the neighboring atoms to that new attachment don't always behave > reliably (as in perhaps don't have the > knowledge that their neighbor has something new attached which affects their > space.) This is the approved way. While you can make links using Coot, it's currently best done with the Acedrg link generator. https://scripts.iucr.org/cgi-bin/paper?ir5021 > As our chemists got more creative, it also is tedious to sit there trying to > make 5 or 6 little bits and pieces that > all have to be attached to different atoms along the scaffold. Plus the > bookkeeping of made up names for little extra > ethylenes, halognes, and their atom name attachment points and such was > pretty painful. It shouldn't be painful and tedious. We recognised that it was so, and that's why Acedrg Link mode was created (Fei Long and Rob Nicholls did most of the work). > So, that led to approach two, which was to just let the dictionary generation > happen for the whole peptide or > macrocycle. This ignores knowledge that it's essentially an amino acid type > of base scaffold (so a bit inefficient for > purists) and just redefines all those as if it's some small molecule, albeit > a relatively large version of one of > those. You also lose residue number indexing, as the whole thing is typically > called "LIG" with a single residue > identifier, but it seems a small price to pay for the convenience of it > taking care of all the sundry modifications > and cyclization points, etc. Hmm.. OK. As you says, swings and roundabouts. > The problem I'm having is that COOT is having trouble reading or using these > large .cif files. The files may be 1000 > or more lines long with the hydrogens defined. It shouldn't pose a problem. > I've tried dropping all hydrogens but it's still large and when I go to real > space refine or do any editing to move > the starting conformation of the molecule in question into the clear density > for it bound to some protein, Coot > basically hangs either indefinitely or for several minutes at a time at least > with each attempted motion, step. That sounds bad. > Is there some memory allocation for the .cif dictionary that perhaps is > limiting? Possibly - I've not seen this problem. > I don't have a handy non-proprietary example currently, but could likely > generate one if needed. Please do - I need to see the problem before I can fix it. Let's fix the "Big LIG" problem first. > Or have people had success with this approach (e.g. taking a 10-14 amino > acid peptide, treat it as a SMILES string > and generate a .cif for the whole thing as a single molecule and then be able > to use it in real space refinement in > Coot? ) I can't comment - it should be straightforward but it seems that it isn't. > I've tried a few workarounds to get the atoms pretty close and then let > reciprocal space refinement do the rest, but > there really aren't so many good ways to do that (Pymol's sculpting drifts, > was playing with Isolde but having similar > technical issues with the restraints definitions). The way forward is clear - we can correspond in private until we have worked out what the problem is. Paul. ######################################################################## To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
