You are here

Prevention of the negatively charged Nitrogen protonation by coupled_moves

5 posts / 0 new
Last post
Prevention of the negatively charged Nitrogen protonation by coupled_moves
#1

Dear sir and madam,

I have met with the unfavourable addition of 2 Hydrogen atoms onto sulfonamide Nitrogen instead one (NH2 instead of NH) on a ligand during the coupled_moves docking application runs. It is perfomed 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::ligand_mode true -coupled_moves::backbone_mover backrub -number_ligands 1 -ligand_mode true -ligand_weight 1.0 -ntrials 500 -pH:pH_mode true -pH:keep_input_protonation_state true -initial_repack true -save_sequences true -save_structures true -mc_kt 0.6 -boltzmann_kt 0.6

My task consists in prevention of the unfavourable proton addition onto NH group.

I have already assigned the negative charge to the sulfonamide Nitrogen on PyMOL by the following commands:
1) edit EZA//A/EZL`306/N1
2) Build -> Make (pk1) Negative

These results are reflected in the PDB file as "N1-". I tried to use both protonated and unprotonated ligand inputs (anyway, Rosetta will protonate all vacant sites).

I have already inspected the Rosetta software suite and found several flags, these might keep atoms in special protonated states. I have already even tried to use flags -pH_mode true and -keep_input_protonation_state true, but it didn't keep the sulfonamide Nitrogen out from unwanted protonation.

I even tried to specify the Nitrogen atom type in .params file, but it seems as if there is no option to mark the negatively charged Nitrogen neither in "GenericAtomTypes.md" file nor anywhere else. Furthermore, marking Nitrogen atom as sp3-hybridized one (NG3) isn't suitable with any Nitrogens' GenericAtomTypes assignment (such as Nbb, Nhis or smth. else). Which Nitrogen atom_type_name may be compatible with NG3 option?

Would you be kind to tell me how to disable protonation option for Rosetta applications, such as coupled_moves, please?

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

Best regards,
Corvin.

AttachmentSize
Ligand3.04 KB
Params file3.33 KB
Flag file569 bytes
Post Situation: 
Wed, 2020-11-18 02:56
Corvin

The PDB file is only used for the atom coordinates - its role in the chemical identity of the compounds is limited to heuristic selection from a set of pre-existing chemical identities. The protonation flags you mention are only used to turn on the use of a pre-prepared set of amino acid protonation variants. They should have little to no effect on the protonation state of a residue not in the standard 20 aa set.

For ligand molecules, the pre-existing set of chemical identities are specififed via the params files. Rosetta assumes that the the atom and bonding pattern specified in your sdf or mol2 file which you passed to the params file generation script is the one you want. If you have extra (or missing) atoms in the ligand, those extra atoms will be specifed within the params file. (Rosetta itself will only add atoms which are present in the params file but missing in the input PDB. It will not attempt to make the compound match with any sort of internal notion of a "reasonable" chemical layout.)

The atom typing information in the params file is only used for score function parameterization. The presence of atoms (and their bonding pattern) is entirely specified by the presence of the ATOM lines (and the BOND lines). The atom types will only change the scoring. (And that fourth column - the one which is mostly Xs - is only used for the "molecular mechanics" energy terms, which are typically not enabled in most standard runs. As such, changing that is unlikely to make any difference at all.)

The params file you posted looks like it has one nitrogen attached to N1. However, the bonding patterns aren't explicitly specified in the PDB output, so display programs like PyMol often have to infer it from proximity. As such, if you have a hydrogen nominally bonded to something else, but in a physical location which looks like it's close to the nitrogen, then it will appear in the program like it's bonded to the nitrogen.

The best approach is to look at the name of the atom, and then track back to where the params file thinks it should be bonded to (and what it's doing in the sdf/mol2 file the params file was generated from.) One thing to keep in mind when doing this is that Rosetta uses atom names to match up the atoms in the input PDB with those in the params file. If there's an atom name mismatch, Rosetta will happily move atoms around, placing a hydrogen which, according to the params file should be over there, over here instead, just because that's where the input PDB placed an atom with that name. The fact that there's nominally odd bond angles and silly distances doesn't really matter - even most protocols won't indicate an issue, unless you're specifically using one of the few energy terms which will report a bad energy for the distorted geometry.

 

Wed, 2020-11-18 05:26
rmoretti

Dear rmoretti,

many thanks for such a detailed answer.

As far as I have understood, the Rosetta software doesn't protonate all vacant sites in order with some implicit protocole. Nevertheless, I have several questions about ligand preparation procedure for making this protocol to work in a proper way.

I prepare it in the following way according recommend procedure from coupled_moves documentation:
So, my ligand preparation looks in the following way:
1) Assignment of negative charge to the sulfonamide Nitrogen.
2) Protonation the ligand by OpenBabel (script on Bash: babel -h eza.pdb eza_h.sdf, where eza_h.sdf - protonated output file). I must admit, that OpenBabel protonates the ligand correctly and treats with atom charges with bigger respect than PyMOL.
3) Saving sdf file as mol2 file on PyMOL.
4) Generation of .params file by the Rosetta Python-based script (by the way, it generated PDB file too). It interprets the sulfonamide NH-group as tyrosine one ("Ntrp" in the third .params column).
5) As PDB input I use ligand with negatively charged sulfonamide Nitrogen and without Hydrogens, gained at Step 1.

My question addresses the problem of preserving the negative charge for Nitrogen during conversion the PDB file into MOL2 one. So, the Rosetta Python script cannot create .params file in a proper way with respect to negatively charged Nitrogen. On the other hand, it seems as if the number of Hydrogens as well as the connection between negatively charged N1 atom and single Hydrogen are written down in a right way. That thing, what the ATOM and BOND lines produce wrong result - the additional Hydrogen, for which both ATOM and BOND records are absent in the .params file - confuses me.

So, the only visible and explicit explanation of such Rosetta behaviour for me is the lost charge mark for this Nitrogen and absense of its denomination in GenericAtomType. Furthermore, the marking of sp3-hybridized Nitrogen (NG3) isn't complete and I don't see any opportunity to arrange NG3 with atom type in the third column (such as Ntrp or Nbb). Besides, it seems as if that the BOND_TYPE for N1-H1 pair also requires its own number (the last column in the BOND_TYPE chapter).

May you say something about atom and bond denominations on MOL2 files, please?

Many thanks in advance.

Best wishes,
Corvin

Fri, 2020-11-20 05:47
Corvin

UPD:

I have already succeeded in the .params file refinement. I cut down on the conversion protocol steps to just turning the initial PDB file into MOL (instead MOL2, because of the MOL format reflects formal atom charges unlike the MOL2 one) bypassing the PDB-SDF-MOL2 file conversion step. So, there negatively charged Nitrogen "CHARGE N1 FORMAL -1" is already present in the .params file. Even more, the partial charge (I imply the last column in the ATOM chapter) of that N1 Nitrogen is the smallest in comparison with such .params files, these were generated by slightly other approaches, as well as the partial charge of attached to it polar Hydrogen.

Nevertheless, the Rosetta is keeping on add the additional, undesired Hydrogen to the NH-group, despite the presence of adequate .params file. All atom names and their bonds are written correctly both in PDB and .params files.
So, my initial suggestion about the innate Rosetta tendency to protonate all vacant sites gains more weight. That Rosetta approach is appropriate for other Rosetta tools (e. g. "Relax"). I would hazard to guess, that there is some statement(s) in some basic protocol code(s), which drive(s) the process of Hydrogen addition to all relevant sites. I would like to find such code statement(s) and turn them off, if it is possible.

May you suggest, how to disable that Rosetta tendency to protonate all sites or point to another solution of some troubleshoot anywhere either in input files or in the Rosetta software itself, please?

I attach my updated .params file for bringing more clarity.

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

Respectfully,
Corvin.

File attachments: 
Mon, 2020-11-23 02:48
Corvin

UPD2:
Dear all,

I have inspected some pieces of code, these underlie the coupled_moves protocol execution, namely these, which are applying the ligand.
I would hazard to guess, that such a code fragment is RotamerSet_.cc file, situated in ~/rosetta_src_2020.08.61146_bundle/main/source/src/core/pack/rotamer_set/ subdirectory. I would like to find out, whether that or any other file is responsible for atom protonation during Rosetta run. Furthermore, I would suppose, that the statement on line 395:

tt << "Using simple Rotamer generation logic for " << concrete_residue->name() << std::endl;

might be related to it on base of that I see such a statement during the Rosetta command execution on Bash:

core.pack.rotamer_set.RotamerSet_: Using simple Rotamer generation logic for pdb_EZL

On the other hand, I have noticed that PDB entries don't preserve formal charges for their atoms and all atoms in outputs have neutral charges. As it could be just another part of the problem or even the problem lies here, I want to know, how to preserve such charges. Unfortunately, such flag commands as -pH:keep_input_protonation_state true or -chemical:set_atomic_charge fa_standard don't work.

The last but not the least question, which interests me is preserving the positive charge (+2) for the Zinc ion. I tried to do it on PyMOL and assigned it to that ion by a flag -set_atomic_charge fa_standard:ZN:ZN:+2. As it has been taking place in previous cases, that Zinc ion also losses its charge and becomes neutral during coupled_moves protocol execution.

I will be really grateful for specifying the exact reason(s) of such Rosetta behaviour and suggested ways to tackle it (them).

Kind regards,
Corvin.

Wed, 2020-11-25 02:58
Corvin