Confusion when searching trees from RAM

[Adam Cossette]

All,

 I taught myself how to use TNT so I may be using it in a different way than yourself – I do not use the command line, I use a mouse on a computer running Windows. I would like to explain how I am getting my MPTs and if you may, please let me know what you are doing differently. The point of this activity is determining the relationships of the ingroup taxa via the creation of a strict consensus. I am using a morphological matrix with 112 taxa, 171 characters, 16 states. Below are the steps I am using to get the MPTs from TNT.

I load the .ss file into TNT, select 1000 megabytes of RAM and set the max trees as 99,999 which is as many as the interface allows when not using the command line.

I do not use collapsing rules for my reconstructions. Collapsing rules = none.

I select a traditional search. Next I select the number of replicates, 1000 for this example, saving 10 trees per replicate and using the TBR swapping algorithm. 

Then I run the search and get 620 trees, but some have overflowed.

Because there was an overflow of replications I re-run the analysis on the trees stored in RAM again using TBR.

During the second round of TBR I get the max number of trees I selected in the beginning, if I set max trees to 10,000 then it returns that many, if max trees set to 99,999 then I get that many. This is where my confusion lies – I’ve looked at many references and cannot solve this issue. A third round of TBR produces the max number of trees selected in the beginning (99,999).

Any advice is helpful! --- Adam

[Mark]

When some replicates overflowed it generally means that while you may have run 1000 replicates, some number of replicates did not get to the best score, that may have been because the replicate hit the tiny number of 10 trees. 

“Hold” is used in two ways. 

Outside of the searching: 

HOLD

    N     set tree buffer to keep up to N trees 

    +N    increase max. trees to number of trees in memory + N (++ = 1 ) 

    -N    decrease max. trees to number of trees in memory - N (-- = 1 ) 

    N/V   set a "tree-vault" in internal memory, where trees can be 

          placed to be protected from other commands (e.g. search commands) 

          This sets max. trees to be N, vault size to be V.  Trees can  

          be placed in the vault, or retrieved, with the "tvault" command. 

          Subsequent execution of the "hold" command  (other than the  

          default ';') resets the vault (discarding trees from the vault). 

And also inside of the mult search where it dictates the number of trees to hold for each replicate e.g.,

mult 1000 =tbr hold 10;

It sounds like what you did was set the outside hold to 99,999 and the mult search hold to 10, and then did 1000 replicates:

hold 99999

mult 1000 =tbr hold 10;

But then you would only need room for 10,000 trees (1000*10) not 99,999 trees.

By restricting your per-replicate trees to only 10, you are not giving each replicate much opportunity to keep rearranging. So, for any given replicate the search is much more likely to hit the maximum number of trees (10) for a replicate and thus “overflow” stop rearranging and move on to the next replicate. 

By example, running the zilla dataset with your parameters I got a best score of 16220 1 time out of 1000.

But if I run 100 replicates hold 10-times as many trees [mult 100 = tbr hold 100] I get a shorter best score of 16219 1 times out of 100 

With room for 99,999 trees, you can actually do 1000 replicates holding 99 trees [mult 1000 =tbr 99] each time instead of just 10.

Alternatively you could run 500 replicates holding 199 trees each time [mult 500 =tbr 199]

Etc

The zilla dataset is in a sense overdefined in that it tends to find one tree each time and it’s just hard to find the shortest one. 

Your data sound like they are under-defined in that there are many many equally parsimonious trees and it’s hard to get past that on any replicate to continue to find the shortest set of many many equally parsimonious trees. 

If you are consistently hitting the same best score, then after a run that results in some number of trees (e.g., 620) it makes sense to discard the other trees that were saved, and then just use those trees to for swapping out to build out a larger scope of equally parsimonious trees up to your maximum 99,999 trees. 

After your mult search you can execute 

best;

to just make sure you have only the shortest trees in memory. 

Then use the bbreak command

bb = tbr;

This will fill out the largest set of equally parsimonious trees with tbr using the starting trees you had in memory from your mult search. 

Then make your consensus with nelsen;

--
Has recibido este mensaje porque estás suscrito al grupo "TNT-Tree Analysis using New Technology" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tnt-tree-analysis-using-n...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/tnt-tree-analysis-using-new-technology/4d17f31c-8a94-4c69-a7ba-56e16c9b671fn%40googlegroups.com.