g_dih -h claims general functionality that g_dih does not have. It does not read the .tpr connectivity, and only infers some backbone dihedral angles from atom names, so it's probably broken for some force fields. As far as I can see, g_angle provides all the functionality g_dih claims, and in my experience actually does so.

Associated revisions

Per the redmine discussion for #1094, g_dih was brokendue to hardcoded atom names while the documentationclaimed dihedrals were assigned from the topology.For now it is better to use g_angle and manually definethe dihedrals. We plan to reimplement g_dih from scratchfor 5.0. Fixes #1094.

Change-Id: I57e0614e4d98bb5d4bbb3aaa1d3ba4377a93f988

History

g_angle does not provide the functionality that is desired, but neither does g_dih. The problem is that all force fields use different names for protein atoms, despite the definition being quite a bit older (1970) than the force fields. This sucks. What you typically want is to get backbone and side chain dihedrals according to the IUPAB definitions. g_dih was probably implemented by me for the gromos FF.

Since the information is not in the tpr, which is force field specific the way around this would be to have some kind of force field translation table. However even this is cumbersome since the force field identifier is not stored in the tpr file.

So I agree that broken tools may give so much headache that it is not worthwhile maintaining. However that means this functionality goes away. A proper rewrite would be in place.

What we probably could do is remove this program from 4.6, and add a feedback issue for 5.0 to reimplement g_dih from scratch.

I still don't see the use case that warrants a separate tool even in 5.0. If the user has to know about atom names, then they may as well be using an index file generation tool and feeding that to g_angle. IMO, if there is an easy and FF-agnostic way to select backbone dihedrals as a user convenience, then the place to implement that is in the index-file generation code.