Re: Glutamic acid protonation

[Anonymous]

Hi,

I am working on an enzyme design project for which I want one of the glutamic acid of the catalytic site to be protonated at OE2 position. I manually did that using schrodinger but when I prepared the structure using relax protocol, the glutamic acid becomes deprotonated. How, I can get a specific glutamic acid (For eg position 43) to be protonated specifically at OE2?

 

Thanks in advance for help

BH

[Anonymous]

Hi,

I tried using the -keep_input_protonation_state option, but still I am not getting the glutamic acid in protonated state even when the input structure contains a protonated glutamic acid.

Looking for suggestions 

 

Thanks

BH

[Anonymous]

Hi,

I tried using the -keep_input_protonation_state option, but still I am not getting the glutamic acid in protonated state even when the input structure contains a protonated glutamic acid.

Looking for suggestions 

 

Thanks

BH

[Anonymous]

Hi,

I tried using the -keep_input_protonation_state option, but still I am not getting the glutamic acid in protonated state even when the input structure contains a protonated glutamic acid.

Looking for suggestions 

 

Thanks

BH

[Anonymous]

Rosetta doesn’t (currently) have a really good way to deal with differing protonation states for various residues. Instead, you really need to treat the protonated residue as a “noncanonical” amino acid distinct from the regular glutamate. There’s a number of previous forum threads on using protonated histidine – doing something similar with GLU is the approach you probably want to take.

Please post follow-up questions if you’re having problems.

[Anonymous]

Rosetta doesn’t (currently) have a really good way to deal with differing protonation states for various residues. Instead, you really need to treat the protonated residue as a “noncanonical” amino acid distinct from the regular glutamate. There’s a number of previous forum threads on using protonated histidine – doing something similar with GLU is the approach you probably want to take.

Please post follow-up questions if you’re having problems.

[Anonymous]

Rosetta doesn’t (currently) have a really good way to deal with differing protonation states for various residues. Instead, you really need to treat the protonated residue as a “noncanonical” amino acid distinct from the regular glutamate. There’s a number of previous forum threads on using protonated histidine – doing something similar with GLU is the approach you probably want to take.

Please post follow-up questions if you’re having problems.

[Anonymous]

Thanks Rmoretti for your response.

In one of your previous response to a similar query you provided some solutions (https://www.rosettacommons.org/node/3618). I am copying it here again:

“In Rosetta3 (or at least later versions of it), we do have protonation states in the database directory, but they’re only loaded if the “-pH:pH_mode” commandline flag is given. But you probably don’t want to enable that, as that would allow the protonated variant at *all* positions of the protein, rather than just the position you’re interested in. Instead, I’d recommend making a “new” params file used for just your location by copying the existing protonated variants, choosing a non-ASP three letter code, altering the IO_STRING line to use the new three letter code, changing the AA line from ASP to UNK, and then, if you’re using Rosetta3.5, adding a “ROTAMER_AA ASP” line to the file. Then it’s simply a matter of including the new params file with the -extra_res_fa flag, and using the new three letter code instead of ASP at the appropriate locations. (e.g. in the constraint file, and in the REMARK lines and ATOM records of the PDB file).”

I tried this option but everytime I endup with a structure without protonated glumatic acid. I have attached the param file and the input/output structure. 

The second suggestion which you provided was : “The other alternative is to simply ignore the proton when doing your modeling. The ASP-ligand interaction is being enforced by the constraints, so you probably don’t need the proton to be actually present during modeling in order for things to work out decently. (If you currently have the constraints written based on the proton, you can always re-write them based on heavy atoms — using heavy atoms for your constraints is something of the recommended way of doing things, anyway.) If your constraints are set up correctly, the presence/absence of the proton will likely not make too much of an issue in most Rosetta runs.” –

I will try this option and I know it will work, as I have already worked on setting constraints for heavy atoms. 

In addition to my above query, I would also like to know that if I want to design other regions of the protein in addition to the active site cavity, for eg., residues 3 Angs (or even farther from the active site) away from the active site, what shall I do? One option is to use the resfile and mutate the residue, but I am not sure how much effect will such mutation have on maintaining the Near Attack Geometry (see ref. provided). Actually, I am following this paper for designing residues with higher catalytic acivitiy – http://onlinelibrary.wiley.com/doi/10.1002/ange.201411415/abstract. Well, in this paper they focussed on stereoselectivity, but I want to utilize the same idea for designing mutants with increased catalytic activity. In the paper, they focussed only on the residues lining the active site, but I want to mutate the residues away from the active site and filter first based on Rosetta and then perform the high throughput MD. I am not sure whether mutating a residue distant from the active site will affect the Near Attack Geometry during Rosetta Modeling and if it affects, what additional options can I use to perturb the structure more during Rosetta modeling ? I hope my query would be clear to you.

Please provide your suggestion and opinion on whether this can be done and how ?

 

 

Thanks 

BH

 

 

 

[Anonymous]

Thanks Rmoretti for your response.

In one of your previous response to a similar query you provided some solutions (https://www.rosettacommons.org/node/3618). I am copying it here again:

“In Rosetta3 (or at least later versions of it), we do have protonation states in the database directory, but they’re only loaded if the “-pH:pH_mode” commandline flag is given. But you probably don’t want to enable that, as that would allow the protonated variant at *all* positions of the protein, rather than just the position you’re interested in. Instead, I’d recommend making a “new” params file used for just your location by copying the existing protonated variants, choosing a non-ASP three letter code, altering the IO_STRING line to use the new three letter code, changing the AA line from ASP to UNK, and then, if you’re using Rosetta3.5, adding a “ROTAMER_AA ASP” line to the file. Then it’s simply a matter of including the new params file with the -extra_res_fa flag, and using the new three letter code instead of ASP at the appropriate locations. (e.g. in the constraint file, and in the REMARK lines and ATOM records of the PDB file).”

I tried this option but everytime I endup with a structure without protonated glumatic acid. I have attached the param file and the input/output structure. 

The second suggestion which you provided was : “The other alternative is to simply ignore the proton when doing your modeling. The ASP-ligand interaction is being enforced by the constraints, so you probably don’t need the proton to be actually present during modeling in order for things to work out decently. (If you currently have the constraints written based on the proton, you can always re-write them based on heavy atoms — using heavy atoms for your constraints is something of the recommended way of doing things, anyway.) If your constraints are set up correctly, the presence/absence of the proton will likely not make too much of an issue in most Rosetta runs.” –

I will try this option and I know it will work, as I have already worked on setting constraints for heavy atoms. 

In addition to my above query, I would also like to know that if I want to design other regions of the protein in addition to the active site cavity, for eg., residues 3 Angs (or even farther from the active site) away from the active site, what shall I do? One option is to use the resfile and mutate the residue, but I am not sure how much effect will such mutation have on maintaining the Near Attack Geometry (see ref. provided). Actually, I am following this paper for designing residues with higher catalytic acivitiy – http://onlinelibrary.wiley.com/doi/10.1002/ange.201411415/abstract. Well, in this paper they focussed on stereoselectivity, but I want to utilize the same idea for designing mutants with increased catalytic activity. In the paper, they focussed only on the residues lining the active site, but I want to mutate the residues away from the active site and filter first based on Rosetta and then perform the high throughput MD. I am not sure whether mutating a residue distant from the active site will affect the Near Attack Geometry during Rosetta Modeling and if it affects, what additional options can I use to perturb the structure more during Rosetta modeling ? I hope my query would be clear to you.

Please provide your suggestion and opinion on whether this can be done and how ?

 

 

Thanks 

BH

 

 

 

[Anonymous]

Thanks Rmoretti for your response.

In one of your previous response to a similar query you provided some solutions (https://www.rosettacommons.org/node/3618). I am copying it here again:

“In Rosetta3 (or at least later versions of it), we do have protonation states in the database directory, but they’re only loaded if the “-pH:pH_mode” commandline flag is given. But you probably don’t want to enable that, as that would allow the protonated variant at *all* positions of the protein, rather than just the position you’re interested in. Instead, I’d recommend making a “new” params file used for just your location by copying the existing protonated variants, choosing a non-ASP three letter code, altering the IO_STRING line to use the new three letter code, changing the AA line from ASP to UNK, and then, if you’re using Rosetta3.5, adding a “ROTAMER_AA ASP” line to the file. Then it’s simply a matter of including the new params file with the -extra_res_fa flag, and using the new three letter code instead of ASP at the appropriate locations. (e.g. in the constraint file, and in the REMARK lines and ATOM records of the PDB file).”

I tried this option but everytime I endup with a structure without protonated glumatic acid. I have attached the param file and the input/output structure. 

The second suggestion which you provided was : “The other alternative is to simply ignore the proton when doing your modeling. The ASP-ligand interaction is being enforced by the constraints, so you probably don’t need the proton to be actually present during modeling in order for things to work out decently. (If you currently have the constraints written based on the proton, you can always re-write them based on heavy atoms — using heavy atoms for your constraints is something of the recommended way of doing things, anyway.) If your constraints are set up correctly, the presence/absence of the proton will likely not make too much of an issue in most Rosetta runs.” –

I will try this option and I know it will work, as I have already worked on setting constraints for heavy atoms. 

In addition to my above query, I would also like to know that if I want to design other regions of the protein in addition to the active site cavity, for eg., residues 3 Angs (or even farther from the active site) away from the active site, what shall I do? One option is to use the resfile and mutate the residue, but I am not sure how much effect will such mutation have on maintaining the Near Attack Geometry (see ref. provided). Actually, I am following this paper for designing residues with higher catalytic acivitiy – http://onlinelibrary.wiley.com/doi/10.1002/ange.201411415/abstract. Well, in this paper they focussed on stereoselectivity, but I want to utilize the same idea for designing mutants with increased catalytic activity. In the paper, they focussed only on the residues lining the active site, but I want to mutate the residues away from the active site and filter first based on Rosetta and then perform the high throughput MD. I am not sure whether mutating a residue distant from the active site will affect the Near Attack Geometry during Rosetta Modeling and if it affects, what additional options can I use to perturb the structure more during Rosetta modeling ? I hope my query would be clear to you.

Please provide your suggestion and opinion on whether this can be done and how ?

 

 

Thanks 

BH

 

 

 

[Anonymous]

There are two changes you need to do to the params file in order to get things to work with Rosetta 3.7. The first is to change the AA line back to GLU. The second is to add “L_AA” to the PROPERTIES line. (The first is needed for basically any version of Rosetta, the latter may not be needed for earlier versions.) Once I make these two changes, I’m able to get your protein read properly in Rosetta 3.7

The second option you mention is only really applicable if you have a enzdes-style constraint from the theozyme/ligand to the protonated oxygen. If you’re attempting to add a hydrogen for other reasons, it might not work very well.

Regarding designing other regions of the protein, this is certainly possible, though how to do it depends slighly on how you’re doing the mutations. Using a resfile is a general option. If you’re using the interface autodetection logic of Enzdes, what you want to do is have the general setting (before the “start”) be “AUTO”, and then manually set the design parameters for  the non-interface residues you want to design or repack. If you pass that resfile to the enzdes program, or the DetectProteinLigandInterface task operation in RosettaScripts, the manual setting in the resfile will override any interface autodetection settings. (So if the residue is manually set to repack only in the resfile, but would be in the design shell normally, it will only get repacked, not designed.)

Desiging residues far from the interface normally has limited utility for increasing enzyme activity or protein/ligand affinity. Rosetta’s energy function doesn’t really count heavy atom/heavy atom interactions more than 7 Ang apart, and so (like most computational programs) it isn’t sophisticated enough to determine subtle secondary shell effects. That doesn’t mean it can’t be productive, but don’t expect to predict those distal mutations which have a big effect on kcat or Km. 

 

 

[Anonymous]

There are two changes you need to do to the params file in order to get things to work with Rosetta 3.7. The first is to change the AA line back to GLU. The second is to add “L_AA” to the PROPERTIES line. (The first is needed for basically any version of Rosetta, the latter may not be needed for earlier versions.) Once I make these two changes, I’m able to get your protein read properly in Rosetta 3.7

The second option you mention is only really applicable if you have a enzdes-style constraint from the theozyme/ligand to the protonated oxygen. If you’re attempting to add a hydrogen for other reasons, it might not work very well.

Regarding designing other regions of the protein, this is certainly possible, though how to do it depends slighly on how you’re doing the mutations. Using a resfile is a general option. If you’re using the interface autodetection logic of Enzdes, what you want to do is have the general setting (before the “start”) be “AUTO”, and then manually set the design parameters for  the non-interface residues you want to design or repack. If you pass that resfile to the enzdes program, or the DetectProteinLigandInterface task operation in RosettaScripts, the manual setting in the resfile will override any interface autodetection settings. (So if the residue is manually set to repack only in the resfile, but would be in the design shell normally, it will only get repacked, not designed.)

Desiging residues far from the interface normally has limited utility for increasing enzyme activity or protein/ligand affinity. Rosetta’s energy function doesn’t really count heavy atom/heavy atom interactions more than 7 Ang apart, and so (like most computational programs) it isn’t sophisticated enough to determine subtle secondary shell effects. That doesn’t mean it can’t be productive, but don’t expect to predict those distal mutations which have a big effect on kcat or Km. 

 

 

[Anonymous]

There are two changes you need to do to the params file in order to get things to work with Rosetta 3.7. The first is to change the AA line back to GLU. The second is to add “L_AA” to the PROPERTIES line. (The first is needed for basically any version of Rosetta, the latter may not be needed for earlier versions.) Once I make these two changes, I’m able to get your protein read properly in Rosetta 3.7

The second option you mention is only really applicable if you have a enzdes-style constraint from the theozyme/ligand to the protonated oxygen. If you’re attempting to add a hydrogen for other reasons, it might not work very well.

Regarding designing other regions of the protein, this is certainly possible, though how to do it depends slighly on how you’re doing the mutations. Using a resfile is a general option. If you’re using the interface autodetection logic of Enzdes, what you want to do is have the general setting (before the “start”) be “AUTO”, and then manually set the design parameters for  the non-interface residues you want to design or repack. If you pass that resfile to the enzdes program, or the DetectProteinLigandInterface task operation in RosettaScripts, the manual setting in the resfile will override any interface autodetection settings. (So if the residue is manually set to repack only in the resfile, but would be in the design shell normally, it will only get repacked, not designed.)

Desiging residues far from the interface normally has limited utility for increasing enzyme activity or protein/ligand affinity. Rosetta’s energy function doesn’t really count heavy atom/heavy atom interactions more than 7 Ang apart, and so (like most computational programs) it isn’t sophisticated enough to determine subtle secondary shell effects. That doesn’t mean it can’t be productive, but don’t expect to predict those distal mutations which have a big effect on kcat or Km. 

 

 

[Author]

Posts