- This topic has 6 replies, 3 voices, and was last updated 12 years, 4 months ago by Anonymous.
July 5, 2011 at 6:47 am #967Anonymous
In the design of the kemp enzyme, a pseudoatom (X1) that represents the aromatic moeity was introduced to define the pi-pi stacking between an aromatic residue and the ligand. The block from the cst file is shown here:
#block 5 for aromatic binding
TEMPLATE:: ATOM_MAP: 1 atom_name: X1 C10 C12
TEMPLATE:: ATOM_MAP: 1 residue3: D2N
TEMPLATE:: ATOM_MAP: 2 atom_type: aroC,
TEMPLATE:: ATOM_MAP: 2 residue1: WFY
CONSTRAINT:: distanceAB: 3.50 0.20 50.00 0
CONSTRAINT:: angle_A: 90.00 5.00 50.00 360.00
CONSTRAINT:: angle_B: 90.00 5.00 50.00 360.00
CONSTRAINT:: torsion_A: 90.00 5.00 50.00 180.00
CONSTRAINT:: torsion_B: 180.00 15.00 0.00 120.00
CONSTRAINT:: torsion_AB: 0.00 0.00 0.00 180.00
My question is how do you define and obtain the coordinates of the pseudoatom? I read from somewhere that you can define a pseudoatom in Pymol, but I couldn’t figure out how. My second question is how do you incorporate the non-existing atom X1 into the starting pdb file so RosettaDesign can recognize it. Thanks for any kind help!
July 5, 2011 at 3:07 pm #5834Anonymous
The easiest way to get the coordinates is to average the six coordinates of the carbon atoms in the aromatic ring you’re adding it to (that’s a simple sum-and-divide-by-six average, for each of X, Y and Z). You would then manually add this in as an extra atom to the mol/mol2 file that you feed to molfile_to_params.py (Don’t forget to manually add a pseudo bond from the virtual atom to the rest of the molecule – molfile_to_params.py doesn’t do well with disconnected structures). For the element symbol, use “X” (special cased to be a “virtual” atom). molfile_to_params.py will spit out a PDB file that you can concatenate onto your protein PDB (you should be doing this anyway, even without the virtual atoms, as molfile_to_params.py will typically rename the atoms, and Rosetta will get confused if the atom names don’t match up properly).
July 6, 2011 at 1:30 am #5835Anonymous
first of all, the cst file block you posted seems to be from the enzdes integration test, which is describing a cysteine esterase active site and not a kemp design.
as to the question, there is an easier way to do this, without having to regenerate the .params file / rerun molfile_to_params.py or changing input structures that you’ve already generated.
you can simply modify the .params file you already have, i.e. add the virtual atom to it. take a look at the D2N_aX.params file that is in the enzdes integration test.
there a 5 lines that relate to the virtual atom in this file (grep for ‘X1’), but only the following three a really necessary
ATOM X1 VIRT VIRT 0.00
BOND C10 X1
ICOOR_INTERNAL X1 0.039321 119.837865 1.401155 C12 C10 C11
the ‘ATOM’ record declares that there is a virtual atom, the ‘BOND’ one says that it’s bonded to another atom (doesn’t really matter which one), and the ICOOR_INTERNAL defines the internal coordinates for the virtual atom in relation to other atoms.
the internal coordiante format means that “atom X1 is 1.4 A away from C12, the angle C10-C12-X1 is 180-119.8 = 60.2 deg and the dihedral C11-C10-C12-X1 is 0.03, i.e. these four atoms are in the same plane. since C10, C12 and C11 are part of the aromatic ring, these internal coordinates put X1 into the middle of the ring.
so, to add a virtual atom to your .params, you can probably copy these three lines, and only exchange the C10,C12 and C11 names with names of atoms in your ring of interest. once you run jobs with this .params file, rosetta should automatically place the virtual atom correctly, even if it is not present in the input structure
now, once you’ve modified your .params file, you should doublecheck whether you placed the X1 atom in the right place. to do so, run a quick scoring calculation in rosetta (adding -output_virtual to the commandline options), and then check where the virtual atom ended up in the output structure.
July 11, 2011 at 9:37 am #5839Anonymous
Many thanks! I think I know how to do that now.
p.s. Florian, may I also ask you what the 2nd and last columns represent in the PDB remark rows from the example given in the enzdes tutorial? Couldn’t find any info online. The remarks also appear to be slightly different before, i.e. REMARK 0 BONE TEMPLATE….
REMARK 666 MATCH TEMPLATE X D2N 0 MATCH MOTIF A CYS 10 1 1
REMARK 666 MATCH TEMPLATE X D2N 0 MATCH MOTIF A SER 98 3 1
REMARK 666 MATCH TEMPLATE X D2N 0 MATCH MOTIF A HIS 144 2 1
REMARK 666 MATCH TEMPLATE X D2N 0 MATCH MOTIF A TRP 100 5 1
July 19, 2011 at 12:06 am #5868Anonymous
if you care to know, the second column is dictated by pdb format for the REMARK records, where characters 7-10 (or something like that) need to be a number. the old rosetta++ code did not honor official pdb format, and the r++ matcher spit out ‘REMARK BACKBONE TEMPLATE’. if these files were read in by mini, they were chopped to REMARK 0 BONE TEMPLATE. i finally changed the mini matcher to spit out some number for the remark, but i had to keep the number of columns constant to ensure backwards compatibility.
the last column relates to a not yet published/documented feature, where multiple geometries can be specified within one cstfile block.
July 19, 2011 at 3:32 am #5870Anonymous
Got it! Thanks to both of you for taking time to answer my questions.
July 13, 2011 at 9:07 pm #5854Anonymous
My reading of the current code is that the content of the second, third, eighth, and ninth columns (the particular number of the remark line, both ‘MATCH’es and ‘MOTIF’) are ignored except for their presence, and anything past the 13th column is ignored completely.
That’s not to say they won’t be used in the future (or weren’t used in the past), so I’d recommend you keep them like the example in the manual to best ensure compatibility going forward.
- You must be logged in to reply to this topic.