Sarah Lutteropp

Added the simulator parameters to the results.csv in https://github.com/lutteropp/NetRAX/commit/09577b7222ffdbef51780344aa55592cd2139004, also updated the first message in this GitHub issue to also list these.

Move type usage statistics (e.g.: We accepted 5 RNNI moves and 2 RSPR1 moves when doing network search from this start network) would be very helpful. NetRAX currently prints these...

Given ArcInsertion moves slow down things a lot (because the 1-Arc-Insertion-Move-Neighborhood is pretty large), it might make sense to deactivate them in the search, and only use the more restrictive...

I wonder if there is a way to build a much smaller, but still somehow similar MSA to the one given to NetRAX. Something like "given this original MSA, reduce...

Other improvement ideas include: - use some pseudo likelihood function, a rough estimation is likely accurate enough during the search - find suitable move candidates faster (e.g., do some ranking...

Yet another optimization idea: If adding reticulations didn't work out with a previous random starting tree, don't try adding them again with the next one...

I agree that these optimizations are for the second paper. Wanted to post them as a discoverable GitHub issue nonetheless.

About the arc insertion moves: The 1-arc-insertion-move neighborhood is extremely large (O(n^3) neighbors), combined with running bruteforce single-threaded and always reoptimizing branches this will take weeks on the cluster... At...

At the very least, I need to parallelize the NetRAX calls from within the Python script used for the experiments...

This commit (https://github.com/lutteropp/NetRAX/commit/44a603acb5077826a462e52ef33fc318ac67e536) reduced the required runtime to run NetRAX search a lot. What it does is redefining the maximum number of reticulations to be the number of reticulations that...