Closed fdimaio closed 5 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 93.14%. Comparing base (
ace29a8
) to head (3dae8c3
). Report is 11 commits behind head on master.:exclamation: Current head 3dae8c3 differs from pull request most recent head dbdf026. Consider uploading reports for the commit dbdf026 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
You should be good to remove the old cartbonded database code:
The DunbrackParamResolver:
Is used by the new dunbrack code, but only a fairly small section of it.
You can see the scope of its usage by my new code here:
It isn't immediately clear to me how to extricate the dead code from the ParamResolver, Since the new code calls from_database, which does a bunch of preprocessing of the database, it isn't as simple as removing unused functions. But I'm pretty sure most of this code is unnecessary now.
Can we remove all of omega, now that it included in a sub-term of another term? Or is that in another PR? Maybe you have already done this, and I'm reading the diff wrong.
This file
and:
Looks like they can be removed, since you added new versions for the BBdependent version.
Can remove: https://github.com/uw-ipd/tmol/blob/0a705c3fa797b0d3ff1258539a3034e8691cff3a/tmol/database/default/scoring/cartbonded.old.yaml along with the other code from cartbonded above.
No code removed from tmol/score/hbond/params.py - other terms seemed to either cut this entirely or partially.
Thanks! Will make these updates.
@jflat06 OK this should be ready for review
This seems fine. It makes me think we ought to come up with some PoseStack-based initialization of the KinForest before we remove the PackedSystem code because we don't want to leave it untested or it will rot; so perhaps getting the PoseStack-based KinForest construction code is a higher priority than I first thought.
I'll give my 'approval' on the parts of the code I am familiar with, but there is lots left that I don't feel confident in approving.
I don't know if we want to handle the trimming down of the DunbrackParamResolver, but it looks like that's still untouched.
Some issues that have come up so far (will be updated as progress continues):
With the latter two it is not clear if these tests are redundant or not. We can look at code coverage to see.
I will next focus on adding a kinematic optimization module