lutteropp
Number of starting networks in NetRAX
We agreed earlier that all random starting networks should be random trees.
5 random starting networks are not enough, even if the "true" network is a tree. RAxML-NG uses by default 10 parsimony + 10 random starting trees. I tried NetRAX (with only 5 random start networks) on a small (10 taxa) tree dataset and it got stuck in a local optimum.
I suggest copying the default from RAxML-NG and also using 10 random starting trees + 10 random parsimony trees in NetRAX. For later, we could think about replacing the parsimony trees by parsimony networks.
How about these two experimental setups:
A: Start NetRAX from 10 random + 10 parsimony trees B: Start NetRAX from only the best RAxML-tree
I implemented the two setups I suggested above. Let's see how it behaves in our experiments now! :)
yes that is what is was about to suggest, we need to explore broadly first to obtain a feeling for who this behaves
On 25.11.20 18:35, Sarah Lutteropp wrote:
I implemented the two setups I suggested above. Let's see how it behaves in our experiments now! :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lutteropp/NetRAX/issues/7#issuecomment-733816270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGXB6XTFNCXJ7YCQ76NSCTSRUW3TANCNFSM4UCROIFQ.
-- Alexandros (Alexis) Stamatakis
Research Group Leader, Heidelberg Institute for Theoretical Studies Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
www.exelixis-lab.org
Turns out 10 random + 10 parsimony trees are a bit much... especially since the current NetRAX version is only single-threaded and not optimized for runtime performance yet (it wastes much time in branch-length optimization and in trying and rejecting arc insertion moves). Trying out what happens if I reduce them by a lot.
just use brute force and the cluster for your experiments
On 30.11.20 02:02, Sarah Lutteropp wrote:
Turns out 10 random + 10 parsimony trees are a bit much... especially since the current NetRAX version is only single-threaded and not optimized for runtime performance yet (it wastes much time in branch-length optimization and in trying and rejecting arc insertion moves). Trying out what happens if I reduce them by a lot.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lutteropp/NetRAX/issues/7#issuecomment-735479287, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGXB6S3MUF2U5DPU6T4VZLSSLOJRANCNFSM4UCROIFQ.
-- Alexandros (Alexis) Stamatakis
Research Group Leader, Heidelberg Institute for Theoretical Studies Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
www.exelixis-lab.org
If we don't care aabout runtime at all: Should I also switch to the slower network search algorithm? So far, I accepted the first move that improved the BIC score. But I already observed that I get a bit better results if I evaluate the entire 1-move-neighborhood and then accept the move that lead to the largest improvement in BIC score...
we don't care about run time for the time being, however applying several moves earlier and quicker may also lead to the desired result, ... to be explored
On 30.11.20 11:13, Sarah Lutteropp wrote:
If we don't care aabout runtime at all: Should I also switch to the slower network search algorithm? So far, I accepted the first moce that improved the BIC score. But I already observed that I get a bit better results if I evaluate the entire 1-move-neighborhood and then accept the move that lead to the largest improvement in BIC score...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lutteropp/NetRAX/issues/7#issuecomment-735658508, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGXB6RQ5VOYC5LZEYATNBLSSNO3RANCNFSM4UCROIFQ.
-- Alexandros (Alexis) Stamatakis
Research Group Leader, Heidelberg Institute for Theoretical Studies Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
www.exelixis-lab.org
With the new wavesearch algorithm, I do not see any advantage in starting from multiple starting trees vs. starting from best raxml-ng tree.
see discussion on slack, starting from several RAxML-NG optimized trees is something we should test
On 17.01.21 02:58, Sarah Lutteropp wrote:
With the new wavesearch algorithm, I do not see any advantage in starting from multiple starting trees vs. starting from best raxml-ng tree.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lutteropp/NetRAX/issues/7#issuecomment-761707985, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGXB6VHOECRMYDU6F4EENTS2IY4HANCNFSM4UCROIFQ.
-- Alexandros (Alexis) Stamatakis
Research Group Leader, Heidelberg Institute for Theoretical Studies Full Professor, Dept. of Informatics, Karlsruhe Institute of Technology
www.exelixis-lab.org