break if both fwd and rev alignments are not okay

[ASLeonard]

At least on same test cases that were getting stuck from #262, this change seems to be enough. If the forward and reverse alignments both fail, it seems reasonable anyway to break out. This doesn't appear to conflict with #288, which still froze at this stage.

The resulting alignment looked fine after checking with pafcheck, so this may not catch every case, but seems to resolve all cases I do have.

[ekg]

Thanks Alex. I've got a PR that shifts the alignment to be pure biWFA, which should at least avoid all the issues we have been running into with the patching. Il mar 29 ott 2024, 03:25 Alex Leonard ***@***.***> ha scritto:

…

At least on same test cases that were getting stuck from #262 <#262>, this change seems to be enough. If the forward and reverse alignments both fail, it seems reasonable anyway to break out. This doesn't appear to conflict with #288 <#288>, which still froze at this stage. The resulting alignment looked fine after checking with pafcheck, so this may not catch every case, but seems to resolve all cases I do have. ------------------------------ You can view, comment on, or merge this pull request online at: #289 Commit Summary - 451668e <451668e> break if both fwd and rev alignments are not okay File Changes (1 file <https://github.com/waveygang/wfmash/pull/289/files>) - *M* src/common/wflign/src/wflign_patch.cpp <https://github.com/waveygang/wfmash/pull/289/files#diff-f33e63d59f3e2d9b6b69d1f1c9261b7c3823bd3df343f8a5749de9a113f5ca0e> (6) Patch Links: - https://github.com/waveygang/wfmash/pull/289.patch - https://github.com/waveygang/wfmash/pull/289.diff — Reply to this email directly, view it on GitHub <#289>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDQEKVRLX5DMGGMV4RWWDZ55A6NAVCNFSM6AAAAABQZISVBSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDANJQGEZDONY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ASLeonard]

I tested that PR tip (263321c) and it still froze with the command

wfmash -s 50000 -l 250000 -p 85 -n 1 -P inf -k 19 -Y "#" -t 1 fa.gz -i mapping.paf > align.paf

but maybe wflign is still the default without adding additional flags. I'll check back once the new PR is merged so I don't preempt anything.

[ekg]

It's designed to work with the default mapping parameters which result in dramatically easier alignments (-s 1k -c 2k -l 3k). There is also a strong possibility of memory management problems, the PR is failing the builds.

…

On Tue, Oct 29, 2024 at 9:48 AM Alex Leonard ***@***.***> wrote: I tested that PR tip (263321c <263321c>) and it still froze with the command wfmash -s 50000 -l 250000 -p 85 -n 1 -P inf -k 19 -Y "#" -t 1 fa.gz -i mapping.paf > align.paf but maybe wflign is still the default without adding additional flags. I'll check back once the new PR is merged so I don't preempt anything. — Reply to this email directly, view it on GitHub <#289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDQEKE3K6FGY4CWGTP4TLZ56N3BAVCNFSM6AAAAABQZISVBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ4DOMZZHA> . You are receiving this because you commented.Message ID: ***@***.***>

[ekg]

So it seems that if you have very large alignment problems, then WF-Line is still almost unavoidably important. I guess the natural thing to do would be to increase the threshold at which we use BiWFA maybe to 100kbp, and still fall back to wflign. In the PR I'm not giving any fallback, only by setting -I should you get the same behavior.

[ASLeonard]

My concern is that if there is any possibility of falling back to wflign (or even via --force-wflign), there currently appears to be a rare set of circumstances in wflign where patching alignments can get stuck in an infinite loop when both forward/backward alignments are not okay.

[ekg]

We can eliminate it entirely for the time being. The existing code has become extremely hard to manage and a rewrite from first principles with clear objectives would be better. Il mer 30 ott 2024, 01:26 Alex Leonard ***@***.***> ha scritto:

…

My concern is that if there is *any* possibility of falling back to wflign (or even via --force-wflign), there currently appears to be a rare set of circumstances in wflign where patching alignments can get stuck in an infinite loop when both forward/backward alignments are not okay. — Reply to this email directly, view it on GitHub <#289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDQEIZQAMWRMMDNVR3C7TZ6B33BAVCNFSM6AAAAABQZISVBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVHE3TGNJTHA> . You are receiving this because you commented.Message ID: ***@***.***>

[ekg]

We should probably merge this in though even if the code path is not used right now. We may resurrect it.