Protect angles in helices when adjacent to prolines

[mnmelo]

The current implementation weakens helical BB-BB-BB angles whenever a Pro is present, which makes sense.

The helical dihedrals, however, are never switched off (shouldn't they be?). Helix BB-BB-BB angles centered on Pro are, therefore, protected by type 10 angles from reaching 180 deg.

Angles involving adjacent residues, however, are problematic because they are also weakened, but not protected by type 10 potentials. This PR fixes that.

[mnmelo]

I also deleted a later block that overrode the unprotected angle for the specific case of proline-centered angles, which left out the adjacent residues. If it all gets protected at the first helix pass, there's no need for later overriding.

Please, do double check I'm not breaking any non-obvious vermouth logic here.

[pckroon]

Hey Manuel, thanks for the contribution!
The link you modified (changed to type 10) applies to helix angles involving a proline in any position. The link you deleted applied to helix angles involving a central proline. This link overrode the angle type to 10.
So I think this achieves what you were aiming for. It's been a long long time since I've done anything with martini simulations however, so I'd also appreciate a review from @csbrasnett before I merge this.

[csbrasnett]

yep, I agree that the change makes sense! Once the tests are fixed, should all be good (though we may have to fix other stuff before merging)

[mnmelo]

So, it turns out that the cascading logic did mind that I deleted that last block (the Pro-centered angles get overridden under some circumstances and need re-setting). I reverted the deletion and it should now be good to go 🤞

There's probably a way to rearrange the angle definitions so that we don't need to re-set Pro-centered angles, but it's probably out of the scope of this PR.

[mnmelo]

@csbrasnett Most tests are passing. The deploy one is complaining about access to tokens since this PR is being made from a fork:

Error: Trusted publishing exchange failure: 
OpenID Connect token retrieval failed: GitHub: missing or insufficient OIDC token permissions, the ACTIONS_ID_TOKEN_REQUEST_TOKEN environment variable was unset

The workflow context indicates that this action was called from a
pull request on a fork. GitHub doesn't give these workflows OIDC permissions,
even if `id-token: write` is explicitly configured.

To fix this, change your publishing workflow to use an event that
forks of your repository cannot trigger (such as tag or release
creation, or a manually triggered workflow dispatch).

This is safe to ignore, I assume?

[pckroon]

We could move the link down in the list, basically giving it a higher priority, but that may cause more issues than it's worth.
And yes, we can ignore the failing test deployment.

Thanks Manuel!

[pckroon]

@mnmelo You accidentally (?) closed this PR before it was merged. Was this intentional?

[mnmelo]

Aww, this was silly. I mistook 'Accepted' for 'Merged' and deleted my fork -- in the process messing up the PR. I'll reopen/create a new one.

[mnmelo]

Please check #675, in which I reactivated the PR.