Re: [COOT] large non-native peptide .cif restraints
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=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/
Re: [COOT] large non-native peptide .cif restraints
Hi Seth, There might be a more straight-forward way, but here is what I would do: - modify a native amino acid to your non-natural residue i.e. in Jligand - assign a new three-letter code and write it out as cif and PDB file - open the cif file in your favorite text editor and define it as L-peptide (or D-peptide), see example for ALA below (keep the exact spacing! So best copy the line from i.e. ALA) data_comp_list loop_ _chem_comp.id _chem_comp.three_letter_code _chem_comp.name _chem_comp.group _chem_comp.number_atoms_all _chem_comp.number_atoms_nh _chem_comp.desc_level ALA ALA ALANINE L-peptide 13 6 . - safe the cif file again. -optional combine all cif files in one file (you can do that in CCP4) - now open all your non-natural amino acids PDBs of your cyclic peptide in coot, move the roughly the order you want them manually and safe them - open all PDBs in your favourit texteditor, use search and replace to renumber them consecutively in the order you want them, and copy them in one PDB file in the correct order - open the PDB file in coot - read in the => since all are defined as peptides and numbered consecutively, coot should generate peptide bonds in between (there might be some hydrogen residues interfering) and RSR should work (I usually check, if the cif definitions make sense, by running a couple of circles structure idealisation in refmac with my compound/ligand etc) - now you just need to add a link to make the circle and define its geometry in the cif file Hope that helps! Best Sabine -- -- Dr. Sabine Schneider Heisenberg Research Group Leader Ludwig-Maximilians University Munich Department of Chemistry Butenandtstr. 5-13 81377 Munich Germany Tel.: +49 (0) 89 2180 77716 https://www.cup.lmu.de/oc/schneider/ On 02/09/2021 01:55, Seth Harris wrote: Hi all, 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.) 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. 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. 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. 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. Is there some memory allocation for the .cif dictionary that perhaps is limiting? I don't have a handy non-proprietary example currently, but could likely generate one if needed. 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'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). Thanks for thoughts, or info on Coot and large .cif dictionaries? Cheers, Seth To unsubscribe
[COOT] large non-native peptide .cif restraints
Hi all, 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.) 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. 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. 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. 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. Is there some memory allocation for the .cif dictionary that perhaps is limiting? I don't have a handy non-proprietary example currently, but could likely generate one if needed. 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'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). Thanks for thoughts, or info on Coot and large .cif dictionaries? Cheers, Seth To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=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/
