dynetan.toolkit.getNGLSelFromNode fails in the case of multiple protein chains with identical residue numbering

[BFedder]

I tried applying Dynetan to a system where a ligand is bound at the interface between two different protein chains. For this, I adapted the tutorial to my system. My protein is a homomer, and I made sure my MDA universe matches the actual structure as closely as possible: Residue numbers are identical to the original PDB structure, and segids and chainIDs are populated correctly. This means that I have multiple residues that are identical in resid and resname that only differ in segid and chainID. I noticed a bug in NGLview when trying to visualise a path with code equivalent to this snippet from Step 2 of the tutorial:

# Select an arbitrary node in the enzyme
enzNode = getNodeFromSel("segid ENZY and resname GLU and resid 115", dnad.nodesAtmSel, dnad.atomToNode)

# Create ball-and-stick representations for node
NGL_sel = dna.toolkit.getNGLSelFromNode(enzNode[0], dnad.nodesAtmSel, atom=False)
w.add_ball_and_stick(NGL_sel)

# Get the optimal path connecting the node selected above to one of the target nondes.
optpath = getPath( trgtNodes[1], enzNode[0], dnad.nodesAtmSel, dnad.preds)

viewPath(w, optpath, dnad.distsAll, dnad.maxDirectDist, dnad.nodesAtmSel)

The issue comes down to dynetan.toolkit.getNGLSelFromNode ignoring any chain or segment information at present. Instead, the visualisation is obviously incorrect, as a residue many nanometers away from the ligand is shown to be connected.

I've fixed it for my system by changing the function from

    node = atomsel.atoms[nodeIndx]
    if atom:
        return " and ".join([str(node.resid), node.resname, "." + node.name])
    else:
        return " and ".join([str(node.resid), node.resname])

to

    node = atomsel.atoms[nodeIndx]
    if atom:
        return f":{node.chainID} and {node.resid} and {node.resname} and .{node.name}"
    else:
        return f":{node.chainID} and {node.resid} and {node.resname}"

but I don't think this is a robust fix. But it might be helpful if getNGLSelFromNode did a few more checks on what information is available in the Universe and adapted its output accordingly?