AddH adds spurious hydrogens when called twice

[Tristan Croll]

Attached PDB of the residue (symmetric dimethylarginine, 2MR) for which I first noticed the issue. If I call addh hbond true on this, it comes out correctly protonated - but if I then make the same call again it's now treated as if the three guanidinium nitrogens are secondary amines - extra hydrogens are added to all three nitrogens and the central carbon. I don't think this behaviour is limited to this specific case - the model I saw it in (6g2g) has a number of other unusual residues which also ended up with strange-looking extra hydrogens.

[Tristan Croll]

dimethylarginine

[Tristan Croll]

Possibly related: in the same model there are two N-terminal prolines that are not true N-termini according to the SEQRES (/X:1 is one of them). Calling addh the first time leaves their N atoms bare, but calling a second time adds a single hydrogen to each. In this case it looks fairly straightforward: the first run changes the idatm_type from N3+ to Npl, so the second time around they get protonated accordingly. Amending addh.cmd.post_add() at line 209 as per the below takes care of that. The formyl- and acetylmethionine residues in the same model are another challenge - their nitrogens get treated as N3+ and doubly- rather than singly protonated.

        for nb in n.neighbors:
            if nb.element.number == 1:
                if nb.name == "H":
                    add_nh = False
                    if fn.name == "PRO":
                        nb.structure.delete_atom(nb)
                else:
                    nb.structure.delete_atom(nb)

[Tristan Croll]

One way to handle the modified N-termini seems to be to simply avoid forcing their idatm_types in _prep_add() as per below. All the formyl- and acetylmethionines come out correctly after this.

    # ensure that N termini are protonated as N3+ (since Npl will fail)
    for nter in real_N+fake_N:
        n = nter.find_atom("N")
        if not n:
            continue
        if not (n.residue.name == 'PRO'):
            # Don't set the idatm_type for non-Pro N-terminal nitrogens 
            # with more than one heavy atom attached to the nitrogen 
            # (most commonly formyl- or acetylated termini).
            heavy_neighbor_count = len([nb for nb in n.neighbors if n.element.number !=1])
            if heavy_neighbor_count > 1:
                continue
        if not (n.residue.name == "PRO" and n.num_bonds >= 2):
            n.idatm_type = "N3+"

[Tristan Croll]

Finally, while playing around I noticed that atom.is_missing_heavy_template_neighbors() kills ChimeraX if called without no_template_okay=True (C++ exception isn't being caught).

[Tristan Croll]

Messing around more with 2MR, it would appear that the underlying bug is in the idatm_type algorithm. If I delete all hydrogens, and select the central carbon and three nitrogens of the guanidinium group:

from chimerax.atomic import selected_atoms
sel = selected_atoms(session)
sel.idatm_types
array(['Ng+', 'C2', 'Ng+', 'Ng+'], dtype=object)

After adding hydrogens:

sel.idatm_types
array(['N3+', 'C3', 'N3+', 'N3+'], dtype=object)

... and if I delete any one out of the three guanidinium hydrogens (HE, HH1, HH2) or either of the methyl groups it collapses back to the correct assignment:

sel.idatm_types
array(['Ng+', 'C2', 'Ng+', 'Ng+'], dtype=object)

[Eric Pettersen]

The 2MR problem is fixed now.

[Eric Pettersen]

Adopted the first suggested change to avoid protonating "fake"-terminal prolines

[Eric Pettersen]

Can you provide an ID that demonstrates the formyl/acetylmethionine problem? 6g2g doesn't seem to have any.

[Eric Pettersen]

Also, not getting the atom.is_missing_heavy_template_neighbors() crash. Can you provide an example?

[tic20@…]

For formyl/acetyl-MET, try 6g2j. Will get back to you on Monday regarding the is_missing_heavy_atoms() crash. I’m off sick at the moment.

 
 

 

[Eric Pettersen]

With with a slightly different solution for the formyl/acetylmethionine problem: leave the assignment of the N alone if the residue didn't receive its IDATM types from a template.

I hope you're feeling better.

--Eric

[Eric Pettersen]

Can reproduce the atom.is_missing_heavy_template_neighbors() crash. Needed to call it on an atom in a non-templated residue.

[Eric Pettersen]

Fixed the atom.is_missing_heavy_template_neighbors() problem.