You are here

Undesirable behaviour of PoseFromSFRBuilder regarding Hydrogen atoms

2 posts / 0 new
Last post
Undesirable behaviour of PoseFromSFRBuilder regarding Hydrogen atoms
#1

Dear Rosetta people,

I am trying to dock ligand, which possesses by sulfonamide NH group to the target protein with a help of coupled_moves application by the following command:

~/rosetta_src_2020.08.61146_bundle/main/source/bin/coupled_moves.default.linuxgccrelease @Options_coupledmoves.txt -resfile target.res -nstruct 2 -coupled_moves::backbone_mover backrub -coupled_moves::ligand_mode true -number_ligands 1 -ligand_weight 1.0 -ntrials 500 -chemical:set_atomic_charge fa_standard:EZL:N1:-1 -set_atomic_charge fa_standard:ZN:ZN:+1 -extra_patch_fa eza_patches.txt -pH:pH_mode true -pH:keep_input_protonation_state true -initial_repack true -bias_sampling true -save_sequences true -save_structures true -mc_kt 0.6 -boltzmann_kt 0.6 > Output.txt

As an output I got sulfonamide Nitrogen with two Hydrogens instead one (originally, X-ray ligand structure doesn't have any protons).
After long throughout inspection of coupled_moves run I found out that the file ~/rosetta_src_2020.08.61146_bundle/main/source/src/core/io/pose_from_sfr/PoseFromBuilder.cc discard all assigned by PyMOL Hydrogens and, further, that Rosetta approach, stubbornly ignoring all carefully written charges, ATOM and BOND records both in input PDB and .params files, protonates them according to its internal order. I would suppose, that the file statement from lines 714-737 is responsible for Hydrogens discarding.

I should notice, that I assign the charge to that Nitrogen, protonate that ligand on PyMOL (because it does the protonation and all conversion preserving atom IDs and their charges) and convert the PDB into MOL2 by OpenBabel. I have already cared about restoring the formal charge -1 for Nitrogen in generated .params file. The patch file for ligand also has been written, but, it seems as if it wouldn't have been taken into account as well as all flags regarding protonation, set_atomic_charge and so on.

I address this question to disable the foregoing PoseFromBuilder statement, which discards already assigned protons or any other problem, which makes the Rosetta to ignore all input records and produce the undesirable products. So far I haven't found the way to disable that statement yet.

I will be sincerely grateful for your response and I am looking forward to it.

Kind regards,
Corvin.

AttachmentSize
Ligand2.53 KB
Params file3.35 KB
Flag file623 bytes
Post Situation: 
Wed, 2020-12-02 04:00
Corvin

The definition for what a residue is for Rosetta is specified by the residue type (which is generated from the params file plus any patches). The PDB input file is only used for the atom coordinates and to heuristically determine which residue type to use. Any "extra" atoms in the PDB file which remain after the residue type takes the coordinates for the atoms it knows about are discarded - that includes any atoms which are misnamed. The process matches up atoms based on name, not on 3D arrangement. Rosetta will also always add back in the atoms which are in the residue type but are missing from the input PDB. Additionally, "extra" information in the PDB such as CONECT lines and charge information will be ignored -- the connectivity and atom property values will be pulled from the params file.

This is somewhat intrinsic to the way Rosetta works. The definition of what a residue is is encoded in the residue type. There isn't any way to turn off the discarding/rebuilding process. If you want different atoms, different rearrangments or different properties (charges), you'll need to make a new residue type (params file/patch), and make sure everything is correctly defined there.

So the solution to your problem is to make sure that the params file is correctly specified and used, rather than trying to muddle with the PDB reader. One thing I note is that your eza_H.pdb file has different hydrogen names than the eza.params file does. You need to match up atom names. Since you're using MOL2 input, there should be atom name information in your input file, but you may need to include the flag `--keep-names` on the molfile_to_params.py command line to prod the script to do a better job of keeping the original names. Alternatively, you could manually rename the atoms in either the params file or the input PDB file, or simply use the PDB file which gets spit out of the molfile_to_params.py file. Another approach would be to add the option `-remap_pdb_atom_names_for eza` to your initial Rosetta run to tell Rosetta to do some heuristic detection of renaming on PDB input. The remapping doesn't always work great, especially for hydrogens, and while it can read in the altered atom names, all the internal names and the output names will still be the ones from the params file.

I'm not sure where the extra hydrogen on the N1 nitrogen is coming from. From the params file and the input ligand, the H01 hydrogen will be discarded and then a new H1 atom will be rebuilt in that location. I don't see a reason why the H01 atom would stick around, and I don't see where another hydrogen will be added. You don't provide your eza_patches.txt, but I don't know if that might cause issues with things. -- Note that if you have a properly prepared params file, you shouldn't need a patch file. Patch files are useful if you have a standard base residue which you then want to have optional modifications -- such as standard (polymeric) Alanine and a tri-protonated N-terminal Alanine. For ligands where you only have one form, making the params file reflect what you want is the better way to go.

I'll also mention that -chemical:set_atomic_charge is used to adjust the partial charge for the electrostatic term. It does not adjust the formal charge for the atom, and it certainly will not cause any sort of protonation/bonding changes to the residue.

 

 

Wed, 2020-12-02 07:27
rmoretti