wrong assignment of CAPRI classes

[taras-stx]

in the static-method compute_CapriClass() of the class StructureSimilarity

there is a wrong identification of CAPRI classes. Example: consider fnat = 0, L-rms = 11 A and I_rms = 2.5 A. The code presented in compute_CapriClass() would classify such example into acceptable category. But the Table II in https://doi.org/10.1002/prot.10393 clearly places it into the incorrect category. All conditions in the compute_CapriClass() need to be fixed.

[CunliangGeng]

Thanks @taras-stx .

The FNAT, L-RMS and I-RMS are not independent parameters, as described in the paper: "We could observe a correlation between the different parameters, particularly between the native contact fraction and the I_RMS, although mainly for predictions reasonably close to the correct solution"

This means it's almost impossible to have I_rms=2.5Å when fnat=0. I'm wondering if the example values you provided are from a real structure model?

[taras-stx]

Thanks @taras-stx .

The FNAT, L-RMS and I-RMS are not independent parameters, as described in the paper: "We could observe a correlation between the different parameters, particularly between the native contact fraction and the I_RMS, although mainly for predictions reasonably close to the correct solution"

This means it's almost impossible to have I_rms=2.5Å when fnat=0. I'm wondering if the example values you provided are from a real structure model?

Yes, you are right. As for you question: I have been working with an unconventional interface of a PP-complex when I encountered such values (sorry, I cannot tell more). Nevertheless, I suggest that the criteria described in Table II of the mentioned paper should be read as:

fNat AND (L-RMS OR I-RMS)

and not the way it is implemented now.

BTW, if one looks in the source code of Rosetta:

main/source/src/protocols/docking/metrics.cc: core::Size calc_CAPRI_rank()

one would see that they treat it as I suggested above. So, if one does not change implementation in compute_CapriClass(), there might be subtle mismatches in classification of the same models when done by Rosetta and pdb2sql

[CunliangGeng]

Thanks @taras-stx. I updated the code based on the conditions described in the paper https://doi.org/10.1371/journal.pone.0161879. Solved in PR #64 , thus closing this issue.