Use 1.0 for good AtomMapping scores, 0.0 for bad AtomMapping scores

[richardjgowers]

Previously 0.0 was used for "good" scores and 1.0 for "bad" scores, so networks could be created according to considering the total sum of all weights across a network as the cost function. This created friction with existing and ongoing efforts, where 1.0 is considered perfect "similarity" and 0.0 is bad/no similarity.

This PR flips scores around to align with community practice.

Developers certificate of origin

• I certify that this contribution is covered by the MIT License here and the Developer Certificate of Origin at https://developercertificate.org/.

[codecov]

Codecov Report

Patch coverage: 95.78% and project coverage change: -0.10% ⚠️

Comparison is base (e797d52) 92.07% compared to head (0fbf018) 91.97%.
Report is 23 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #529      +/-   ##
==========================================
- Coverage   92.07%   91.97%   -0.10%     
==========================================
  Files         113      116       +3     
  Lines        6938     7054     +116     
==========================================
+ Hits         6388     6488     +100     
- Misses        550      566      +16     

Files Changed	Coverage Δ
openfe/protocols/openmm_rfe/_rfe_utils/relative.py	82.84% <ø> (-0.12%)	⬇️
openfe/protocols/openmm_rfe/equil_rfe_methods.py	94.02% <ø> (ø)
openfecli/commands/gather.py	85.25% <90.19%> (-6.79%)	⬇️
openfe/protocols/openmm_rfe/equil_rfe_settings.py	100.00% <100.00%> (ø)
openfe/setup/atom_mapping/lomap_scorers.py	100.00% <100.00%> (ø)
openfe/setup/ligand_network_planning.py	100.00% <100.00%> (ø)
openfe/tests/protocols/test_rfe_tokenization.py	97.14% <100.00%> (ø)
...nfe/tests/setup/atom_mapping/test_lomap_scorers.py	100.00% <100.00%> (ø)
openfe/tests/setup/test_network_planning.py	100.00% <100.00%> (ø)
openfe/tests/utils/test_system_probe.py	100.00% <100.00%> (ø)
... and 6 more

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hannahbaumann]

This looks good to me! Should we check whether networks generated with the flipped score match networks generated using the original score?

[Yoshanuikabundi]

Just a few nits with docstring style and phrasing.

[Yoshanuikabundi]

👍

[IAlibay]

Should we check whether networks generated with the flipped score match networks generated using the original score?

Is test_minimal_spanning_network_regression sufficient here? Ottherwise I agree, we probably should consider a more in-depth check.

[richardjgowers]

I'll check with Ben once he's back, but I think the perses scorer already was in this direction, so that doesn't require flipping

[richardjgowers]

@IAlibay this is the regression test here: https://github.com/OpenFreeEnergy/openfe/blob/main/openfe/tests/setup/test_network_planning.py#L198

It looks like a non-trivial (it's not just radial, it's got plenty of edges) network, so I doubt we'd be getting it through luck if we hadn't correctly done this change

[IAlibay]

@richardjgowers am I good to merge here? Would be good to unblock this for @hannahbaumann to test out the newly generated MSTs.