Encouraging better packing in enzyme_design

[Anonymous]

I’m using the enzyme_design program to redesign an enzyme binding a ligand and have made an initial attempt to replicate the native structure. I’ve created parameter files for the two ligands (using the molfile_to_params.py script and setting –recharge=0 for each) and am using a resfile to indicate the atoms binding the ligand.

 

When I run the enzyme_design program, it generates results where large residues have been replaced with smaller ones (e.g. TRP -> GLY and PHE -> THR) and the ligand is not as tightly packed as in the native.

 

I’ve tried adding the ligpackerweight flag using values as high as 10, but this doesn’t seem to have any effect.

 

I’ve also tried using the enzdes.wts file by using the flag:

-score:weight $ROSETTA3/../main/database/scoring/weights/enzdes.wts

 

but that also hasn’t made any difference.

 

Are there any changes I can make that would encourage better packing of the ligand?

 

Thanks,

 

Jens

[Anonymous]

One thing you might want to try is to use a “soft rep” energy function for your design. These energy functions have softened repulsive potentials, such that larger amino acids can be “squeezed” into spaces where the standard “hard rep” energy functions would see them as a clash. The thought is that this should compensate for the discrete-rotamer approximation during packing: with soft rep you can fit in an almost-but-not-quite fitting rotamer, which can then be minimized ever-so slightly off-rotamer in a subsequent minimization stage.

The traditional soft-rep weights file used for enzyme design is the ligand_soft_rep.wts. However, this (like enzdes.wts) has been optimized for a -restore_pre_talaris_2013_behavior environment. — That’s not recommended for general use anymore. Instead, you should probably be using the most recent energy function (ref2015), which has its own soft-rep energy function (ref2015_soft). — Though you may have to alter them a bit to work with enzdes, as enzdes assumes you have on the the constraint terms and the `chainbreak` energy. There’s a ref2015_cst scorefunction with the appropriate alterations for the hard-rep ref2015 energy function, but no pre-existing ref2015_soft_cst scorefunction. — But it should be easy enough to put together by applying to ref2015_soft the same six-line addition that’s the difference between ref2015 and ref2015_cst.

[Anonymous]

Thank you for the suggestion.

I couldn’t find any files named ref2015 within the rosetta database, the nearest I could find were those named beta_nov15. I took the one named beta_nov15_soft.wts and added the lines:

chainbreak 1.0

coordinate_constraint 1.0

atom_pair_constraint 1.0

angle_constraint 1.0

dihedral_constraint 1.0

res_type_constraint 1.0

as defined in beta_nov15_cst.wts

When I ran this with the enzyme_design excutable and adding the flag “-score:weights beta_nov15_soft_cst.wts”, Rosetta complained:

beta_nov15_soft_cst.wts may be a ‘beta’ scorefunction, but ScoreFunctionFactory thinks the beta flags weren’t set.  Your scorefunction may be garbage!

is this something I should be concerned about or is this just a consquence of the filename? And if I’m using the wrong files, could you point me at the files I should be using?

Using the above weights file didn’t make a marked improvement with the packing (even upon adding the -packing:soft_rep_design and -lig_packer_weight 10.0 flags)

Additionally, the case I’m looking at has two ligands, and I’m using constraints defined in a cst file to hold them in a defined orientation as this determines the catalytic activity  I’m trying to optimise for. It doesn’t appear that the constraints are being honoured as the orientation of the ligands is changing well beyond what I’m specifying in the cst file. If I look in the log file I see:

protocols.toolbox.match_enzdes_util.MatchConstraintFileIfo: WARNING: No appropriate atoms found for entry 1 in constraint 1

protocols.toolbox.match_enzdes_util.MatchConstraintFileIfo: WARNING: No appropriate atoms found for entry 2 in constraint 1

protocols.toolbox.match_enzdes_util.EnzConstraintIO: read enzyme constraints from ../constraint_SAM_SAX.cst … done, 1 cst blocks were read.

protocols.toolbox.match_enzdes_util.EnzConstraintIO: Generating constraints for pose…

protocols.toolbox.match_enzdes_util.EnzConstraintParameters: for block 1, 3 newly generated constraints were added

protocols.toolbox.match_enzdes_util.EnzConstraintIO: checking cst data consistency for block 1…  done

protocols.toolbox.match_enzdes_util.EnzConstraintIO: Cst Block 1done…

protocols.enzdes.EnzdesBaseProtocol: Catalytic residues (pose numbering) are: 360 361

protocols.enzdes.EnzdesFixBBProtocol: Done setting up the task and constraints…

The first line would indicate there is a problem with the constraints, but then everything else indicates that they’ve been read correctly. As far as I can tell, the atoms named in the constraints file are in the scaffold that I’m using, so is there any way I can dig deeper into what’s happening?

 

[Anonymous]

Ah, ref2015 being the default happened the middle of 2017, so if you’re using a Rosetta release before that (e.g. Rosetta 3., the default isn’t ref2015 but talaris.  (And you’re correct that prior to being called ref2015 it was called beta_nov15). There’s three ways you can address this. The first would be to keep with the defaults for your particular version of Rosetta, in which case you’d want to redo things with the talaris2014_soft weights file. The second (and easiest), is to just add the -beta_nov15 option to the commandline to switch things over to the ref2015/bet_nov15 environment. The third is to upgrade to a recent weekly release and use that with the ref2015.

I don’t think it’s in the version you’re using,  but recently a new experimental score term was added to encourage better packing behavior during design. See https://www.rosettacommons.org/docs/latest/rosetta_basics/scoring/VoidsPenaltyEnergy for details.  You might want to try using it and see if that improves things. But to do this you’ll need to upgrade to a more recent version of Rosetta.  You can either use a recent weekly release, or Rosetta 3.9 should come out “real soon now” (and will likely be identical to the most recent weekly release).

 

Regarding not applying the constraints, I’m not sure. You might want to turn up the volume of tracer output (e.g. add `-out:level 500` to the commandline) and see if that gives you anything. The other thing I’d recommend is to double-check all of the residue names, the atom names and all the formatting of the constraint file, to make sure it’s what you think it is. You also might want to try deliberately breaking the constraint file to see if Rosetta errors out appropriately. — Failing that, feel free to post the constraint file and input PDB here and we can see if anything obvious sticks out.

[Anonymous]

Thank you for your very helpful advice.

I’ve upgraded to the latest weekly release and have amended the re2015 weights, and using the enzyme_design executable the packing now seems much better, so thank you again for that.

All of the data relating to the constraint seems correct. If I change any of the parameters to incorrect values (i.e. non-existing atoms, residues, constraint blocks, etc) then ROSETTA crashes with an error. I actually realise now that my initial concern about the parameters being ignored may have been incorrect, as it seems that it was the final repack/minimization without the catalytic constraints that was causing the ligand geometry to become distorted. If I run with the  -enzdes:no_unconstrained_repack the geometry is much better. However, I’m still a bit puzzled by the messages that state:

protocols.toolbox.match_enzdes_util.MatchConstraintFileIfo: [ WARNING ] No appropriate atoms found for entry 1 in constraint 1

protocols.toolbox.match_enzdes_util.MatchConstraintFileIfo: [ WARNING ] No appropriate atoms found for entry 2 in constraint 1

particularly now that I know that if I change the atom types in either constraint that the code actually crashes. In case it’s helpful I’ve attached the scaffold pdb. The constraint I’m using is:

CST::BEGIN

    TEMPLATE::    ATOM_MAP: 1 atom_name: S1 C5

    TEMPLATE::    ATOM_MAP: 1 residue3: SAH

    TEMPLATE::    ATOM_MAP: 2 atom_name: C1 O2

    TEMPLATE::    ATOM_MAP: 2 residue3: SAX

    CONSTRAINT:: distanceAB:    5.00   0.50 100.00 0

    CONSTRAINT::    angle_A:   97.40   5.00 100.00 360.00

    CONSTRAINT:: torsion_AB: -26.20    5.00 100.00 360.00

CST::END

I’ve tried running the design using rosetta scripts so that I have more control over the different parameters and also so that I can experiment with the VoidsPenaltyEnergy and eventually run the jobs under MPI. However, if I run with rosetta scripts EnzRepackMinimize mover and use the new weights for the scorefxn_minimize and scorefxn_repack attributes, I see the following output:

core.scoring.ScoreFunctionFactory: [ WARNING ] **************************************************************************

*****************************************************

****************************************************

talaris2013_cst may be a ‘talaris’ scorefunction, but ScoreFunctionFactory thinks the -restore_talaris_behavior flags weren’t set.  Your scorefunction may be garbage!

I don’t see this error message if I use the PackRotamersMover and set the scorefxn attribute to be the same weights so I’m not sure why this message is only appearing when I’m using EnzRepackMinimize?

 

[Anonymous]

I’m just bumping this as I’m still wrestling with the constraints not being respected.

I thought they might be, but I’ve now run a number of additional tests and with or without the -enzdes:no_unconstrained_repack flag, the geometry between the two ligands is frequently being distorted far beyond what is specified in the constraint. However, I can’t see anything wrong with the constraint or the PDB scaffold.

[Author]

Posts