fix: correct deletion_value coefficient (was 4x too large)

[Pana-TsK]

Summary

deletion_value is meant to be (2/π)·arctan(deletion_count/3) per AF2/AF3. The coefficient was computed as
2.0 / torch.acos(torch.zeros(1, ...)) * 2, which due to left-to-right operator precedence evaluates as (2.0/(π/2))*2 = 8/π instead of 2/π — exactly 4x too large. Verified numerically (coefficient 2.5465 vs. intended 0.6366) and with a hand-computed value: for deletion_count=3, atan(1) = π/4, so the correct output is exactly 0.5; the prior code produced 2.0.

Fires on every MSA row with any deletion — real alignments almost always have some — so this affects the deletion_value channel of msa_feat for essentially every training example and inference query.

Changes

Replaced the acos-based π computation with torch.pi directly (already used elsewhere in this pipeline, e.g.
input_embedders.py:602), removing the precedence trap rather than just adding parentheses around it.

Testing

Added regression tests in openfold3/tests/core/data/pipelines/featurization/test_msa.py: a hand-computed exact value (deletion_count=3 → 0.5) that can't pass by coincidence, plus a comparison against an independently-implemented
reference formula across a range of deletion counts. Both fail against the prior code.

Other notes

Same caveat as #346: this changes what the model sees as input, and I don't know what code snapshot the released checkpoint was trained from, so it may carry the same compatibility risk as #312.

[jandom]

hi there @Pana-TsK you are correct and thanks for this fix, this has been fixed in the upcoming release (the newly trained model was trained with the fix). I'll merge it here so that anybody training from scratch takes the benefit, for fine-tuning the impact should be minimal.

Because this code-branch stays compatible with our P2 weights, I'll delay merging this (which will be a noop) until the upcoming release.

[Pana-TsK]

Hey @jandom, thank you for your swift review! I really appreciate your time, and you and your teams' great work on OpenFold-3. It is an amazing piece of sofware.

I have a few questions:

• This is the second time I hit a bug that was already caught. Is there maybe somewhere a list of all the bugs that are already reported, and are planned for a second release? If I know where they are, this would waste less time both for me and for you.
• A lot of these bugs could have been avoided if they had better test coverage. In your new openfold-3 release, will there be better coverage, and will the code be very different? For most of the bugs I found, better test coverage would have caught them. I am willing to write tests whenever I have free time, if this is something that would interest you.

[jandom]

Our thanks are to you and other members of the community that help improve this codebase @Pana-TsK .

Please accept our apologies, we should communicate better about the bugs that were already closed. I know Jennifer reached out to you, we'll debating some ways of doing this.

Many thanks and we welcome further contributions from you, seems like you got a real one that's not fix – third time is the charm :P