-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to Search in Waves #30
Comments
Done in dd6dd2a. |
I entirely rewrote it in fa50575. NetRAX is still fighting with failing assertions here and there (some branch lengths issue, likely caused by me trying to switch to only use the branch_lengths array in network inference/ likely broke something there)... But it already looking like this search strategy finds the network much faster. Also, it only has to start from raxml-ng best tree. |
Search in waves rocks! :) Here a few more arguments for it, taken from the Slack channel:
|
I highly advocate for exclusively using the search in waves strategy, at least in the first paper. It has so much optimization potential! I especially like that it allows us to (as a heuristic) reuse the old blob optimization code etc (NEPAL likelihood) within the waves... |
So far, search in waves just randomly adds a reticulation to the new network for the next wave (the within-wave horizontal moves are then used to reposition the reticulation). Later (for the second paper), we can try to speed this up by making use of the ideas from the whiteboard meeting (pdf attached) to find positions where a reticulation is likely more beneficial... |
Another reason why search in waves might be working so much more nicely right now: Only adding/removing reticulations messes up the pmatrix- and clv-indices (because they change number of nodes/edges). The search in waves could just be better at avoiding some bugs that can happen when not correctly taking care of these index changes... |
that all sounds great Sarah :-)
…On 09.12.20 17:01, Sarah Lutteropp wrote:
Another reason why search in waves might be working so much more nicely
right now: Only adding/removing reticulations messes up the pmatrix- and
clv-indices (because they change number of nodes/edges). The search in
waves could just be better at avoiding some bugs that can happen when
not correctly taking care of these index changes...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGXB6TMY6CV4T6FAVTNY73ST6GLVANCNFSM4UR2EP2A>.
--
Alexandros (Alexis) Stamatakis
Research Group Leader, Heidelberg Institute for Theoretical Studies
Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
www.exelixis-lab.org
|
So waves is the strategy in this drawing ? If yes, I totally agree that we go for this, and I thought that I had already advocated for it at the beginning of the project (in slack so I am not sure and we will never fund the info, github is super!) It is also discussed in the "moves" paper with Fabio. |
@celinescornavacca Yes! :) NetRAX fully switched to the search in waves now. I have also added an arrow back, to check whether an arc removal in the best found n+1-reticulations network leads to a better n-reticulation-network than what we encountered so far. If this is the case, redo the n+1-reticulation-search from that updated/improved n-reticulation network. |
In the whiteboard meeting today, we discovered some challenges with the current network topology search algorithm.
The text was updated successfully, but these errors were encountered: