CaCb Model can give Excluded Volume > Interaction Distance

[TensorDuck]

Just wanted to inform everyone of something I found. I'll be working this problem this week:

For native interactions, some of the excluded volumes used are larger than the actual interaction distance. This leads to a case that looks like this:

This occurs only for Cb-Cb interactions so far. I found this out for BPTI recently when I was double checking other things.

I don't think it's a bug, but rather a consequence of how we've designed our model. My guess is that you can imagine cases where the side-chains are stacked on top of eachother (due to flat rings), but those would be large residues.

[ajkluber]

Yeah, this is an unexpected property of Gaussian contacts for certain values of the parameters. Are you saying that rNC is greater than r0 in this case?

I have experienced this potential shape before when rNC is less than r0 but the contact strength (or contact width) for the corresponding Gaussian is too small. Since I was working with non-native contacts my solution was to make width larger. However, I think the case you have mentioned with excluded volume is a more serious problem since it effectively introduces unintended barriers to contact.

Have you implemented a solution to this issue? If you haven't, I suggest that you reset rNC for contacts that have rNC < r0 to some percentage of r0.

[TensorDuck]

Yes,rNC is greater than r0 in this case, same well width as we have been using before. Upon further investigation, this only happens for r0 less than the excluded volume by several angstroms: i.e. in disulfide bonds. The cases I found were bonds that should've been disulfide bonds, and as far as I know, the current model_builder package recognizes them as such (just not my test script).

Here is what we get for a small difference, fractions of an angstrom:

Compared to something typical:

The only difference is this slight hydration barrier... but it's so small it's probably okay for our previous simulations. It's also provably that for r>r0, the slope is always positive for rNC < r0.

In principle though, rNC > r0 in principle is bad though, so we should fix this. We were planning on discussing how to refactor the code soon, so I would table any minor bug fixes for after that.

[ajkluber]

In practice I have just reset the excluded volume distance to a fraction of r0 whenever r0 < rNC. Should we implement a check in inputs.py or expect the user to handle it? Right now we tacitly assume the user has handled it and things have gone okay, so I suggest we stick with that.