Filter models based on global RMDS

[AnnaKravchenko]

Desired feature/enhancement

Let filter module use global RMDS value, calculated in caprieval.

Motivation

This is handy when scoring AI-generated models, if one of the molecules in a complex is known to have a determined [to some degree] structure, e.g. antibody. Since AI is known to separate H and L chains (making “broken antibody”) and to put another molecule between them, it would be nice to make filter be able to exclude such broken antibodies automatically.

Description

• pre-reqirement is to merge H+L, which is pretty much a standart practice
• run caprieval with an antibody unbound or modelled in isolation set as reference;
• run filter with appropriate threshold (can be determined by examining a couple of models manually and then restarting the run from filter)

Implementation

I think of writing rmds field into io.json of caprieval, and then adding this rmds as another filtering option in filter module. From what I understand no need to change PDBFile class, load from libontology will be able to add a new field.

Additional context

I did this while scoring one of the capri targets, but at that moment I had to remove complexes with broken molecules manually.

[rvhonorato]

Let filter module use global RMDS value, calculated in caprieval

Keep in mind the modular design, this approach adds a dependency between two modules: filter (using rmsd as argument) will need caprieval to be executed before. By doing this you are spreading a single functionality across two separate domains - which is fine and works (and probably such design rot is already seen in other parts of the project), but this approach is not modular.

Remember the idea of having a modular software is that you can compose workflows, and for this workflow composition to be flexible, each module should be able to handle its own purpose.

If you need a module that can filter based on a metric, this module should also calculate the metric so it's self-sufficient. Yes, maybe the metric was already calculated before and there is no need to do it again - but this is an issue of caching. To avoid multiple calculations there needs to be a system that will avoid doing the same work multiple times and this is a different issue.

So for this case it seems that what you need instead is a new filter_by_rmsd module - yes maybe some feature overlap with another module, but this is the cost of having a modular architecture.

[AnnaKravchenko]

Wouldn’t it be overkill to implement an entire module for such a simple filtering step? And wouldn't such a module largely duplicate existing functionality?

While modularity is beneficial and in the core of haddock, in this case couldn’t it be relaxed - similar to how clustrmsd depends on a precomputed RMSD matrix for a good reason? and given that this filter module alredy requires precomputed scores asis? and given that some other analysis modules do require models to be already scored (or clustered), which is perfectly natural for analysis module ?

I think enforcing such a strict modularity for such a lightweight addition does not seem justified

[amjjbonvin]

You only need a simple RMSD calculation. And then it becomes an independent module indeed.

[rvhonorato]

similar to how clustrmsd depends on a precomputed RMSD

As I said before, this existing is already a sign of design rot - an implementation that breaks modularity and should not be used as an example.

I agree with Alex here Rmsd calculation is a trivial operation and I do not see how it would be overkill.

Again duplication is a cost of modularity, if were to remove all the code that makes this project modular we would easily reduce it in more than 80%.

[AnnaKravchenko]

Writting entire module will take considerably more effort, I wil mark it as a long-term issue then

[amjjbonvin]

The simplest option might be to start from the CAPRIeval module and strip out anything not needed.

[rvhonorato]

similar to how clustrmsd depends on a precomputed RMSD

see #1530