This is a question about the result displayed in MEGA5, not about the interpretation of the missing bootstrap value.

1. Paolo is right - in the tree explorer of MEGA5 click the toolbox icon (brings up the M5: Tree Options window), Choose the Branch tab, there is a tick box there for Hide values lower than x% - you choose the x value. The default option in MEGA5 however is that the tick box is clicked off (and default x=0 so even with the box ticked it will show bootstraps for all applicable branches by default). So if you haven't changed this the explanation is elsewhere.

2. Bootstraps measure support for splits between groups > 2 taxa on either side of the branch (taxa in the group vs those excluded). By definition there is no such thing as a bootstrap on a terminal branch.

3. As Richard says above, bootstrapping treats all trees as unrooted but we view these trees in MEGA5 with the basal branch bent like a hairpin (so that it actually looks like two branches, one on either side of a default midpoint root). The bootstrap value will only be seen on one side of this basal branch (on the lower arm).

4. If you are looking at the original tree rather than the bootstrap consensus it is possible that you do have a branch that had no bootstrap support - I'm not sure what MEGA5 would show in that case (0% or no value) - but this is unlikely as any grouping.

If none of these explain your missing bootstrap then it is possible that you have discovered a bug in MEGA5 - there seem to be a few. I suspect another one is that in the bootstrap consensus tree MEGA5 doesn't collapse branches below your threshold value into polytomies.

Richard, thanks for some good comments here. An alternative way to view bootstrapping is as a random re-weighting procedure which shows how much a branch relies on particular characters. Individual characters are selected at random when constructing each bootstrap pseudoreplicate dataset, with each character represented from 0 to as many times as there are characters, but keeping a mean of one occurrence as in the original data (it is the variance about this mean, and particularly the proportion of sites that are not represented in a particular pseudoreplicate that gives differential support from different replicates). The number of times a character is represented in a bootstrap pseudoreplicate dataset is equivalent to a weighting on that character when analysing that dataset. If a branch in your dataset has robust support, with many characters supporting that split and few characters opposing it, then at least some of these characters will be included, some multiple times, in each pseudoreplicate and that branch will be well supported. If a split has few uncontested characters supporting it then it will be present in a low percentage of pseudoreplicates - which is our bootstrap support value.

Sorry about the long post - one last general point about bootstrapping which might be of interest. Bootstrapping fails to give an accurate measure of support for very recent splits. This is especially important to keep in mind for reconstructing phylogeographic gene-genealogies, where ancestral sequence alleles co-occur with their own descendent sequences. This is one reason why it is usually better to view gene-genealogies within populations as unrooted trees, or networks, rather than as rooted trees (the other reason is because if there is uncertainty about connections a network allows you to show all options and some measure of support for these - but can lead to very complex diagrams). Bootstrapping works by assessing character support in the presence of homoplasy. If you have phylogeographic data, for example from a coding gene, with no more than a handful of substitutions separating any two alleles, and few missing intermediates, then you may have very high confidence of the splits among these sequence alleles (or haplotypes if you prefer that much abused term) but very low bootstrap values. This is because there are 1 or few changes among adjacent alleles in the tree, and this one character will be absent from a high proportion of bootstrap pseudoreplicates. In a dataset of 100 characters you need at least 3 uncontested synapomorphies to generate a 95% bootstrap support - even though there may be little uncertainty about relationships with 1 or 2 uncontested supporting characters. Of course, to some degree you can address this problem with longer sequences but this will also split identical haplotypes into several similar ones. At the limit you can sequence whole genomes without resolving the issue. This is why the coalescent methods of statistical phylogeography provide better ways of analysing support for relationships in phylogeographic data.

I assume you are referring to Drosophila and anopheles. Boot strapping requires a minimal of 3 sequences. Check other instances and see if this correlates to sequences in clads of only 2.

Possibilites:

1-) The boostrap of the node w/ no bootstrap are below the selected bootstrap to the displayed ( see Mega options)

2-) The branches have colapsed in a politomy if they are under a given bootstrap value ( which can also be set up).

It only happened at one node per phylogenetic tree. I have not noticed it at multiple nodes. It will be on one node which act as inter-node. If add more sequences and your inter-node get shifted from these sequences, then you will have bootstrap value for your desired node. I dont know how well I could explain it?? But at internode you will not get bootstarp value.

The node without bootstrap means the relationship of that particular node is not clearly defined among different species.

When you get a node without bootstrap support, it shows that the relationships between the species of that particular node are not certain, thus the branches collapse into polytomies in a consensus tree. Additional data and/or taxa could help to increase the resolution.

Indeed, I suspected filtration but could not find evidence in the manual.

You always found one inter-node without bootstrap.

*Nodes* never have bootstrap values! Bootstrapping applies to a BRANCH. MEGA displays them at one end of the branch, which makes it look like it's associated with the descendant node but it is not. If in doubt, unroot the tree and look at it. You should notice that all of the internal nodes have bootstrap values unless you have selected the option in MEGA to hide values below a certain %.

I wonder about the definitions. Bootsrap values indicate what fraction of the boostraps support the joining of the same clades, isn't it? In that case, it IS pointing to an internal node (or the common branch above it), isn't it? If a node signify a common ancestor, why isn't the bootstrap value indicate the fraction of runs in which the same common ancestor is inferred?

Bootstrap values support the number of times a *branch* appears in the randomised bootstrap data. (i.e. the number of time the tree is split into two in that way.) It supports a clade in the sense that you can think of each side of the branch as a clade. If the tree is rooted then the descendant node does indeed define a clade that matches the branch. (What you are calling the "common branch above it".) The bootstrapping itself is referring to the ancestral *branch* and not the node, though. This is important if the tree is unrooted or, perhaps worse, re-rooted in such a fashion that the ancestry "direction" of the branch is flipped. In other words, bootstrap values are always associated with specific branches but are only associated with specific nodes in a context-dependent fashion. It is a common but sometimes dangerous fallacy to associate bootstrap values with nodes. (Re-root your tree a few times on different branches and see what I mean.) It is also important to remember that the root itself is rarely bootstrapped (although it could be done in principle) and that bootstrap values are generally calculated on unrooted trees - the branches each side of the root are the "same" branch in terms of the bootstrapping.

This is a question about the result displayed in MEGA5, not about the interpretation of the missing bootstrap value.

1. Paolo is right - in the tree explorer of MEGA5 click the toolbox icon (brings up the M5: Tree Options window), Choose the Branch tab, there is a tick box there for Hide values lower than x% - you choose the x value. The default option in MEGA5 however is that the tick box is clicked off (and default x=0 so even with the box ticked it will show bootstraps for all applicable branches by default). So if you haven't changed this the explanation is elsewhere.

2. Bootstraps measure support for splits between groups > 2 taxa on either side of the branch (taxa in the group vs those excluded). By definition there is no such thing as a bootstrap on a terminal branch.

3. As Richard says above, bootstrapping treats all trees as unrooted but we view these trees in MEGA5 with the basal branch bent like a hairpin (so that it actually looks like two branches, one on either side of a default midpoint root). The bootstrap value will only be seen on one side of this basal branch (on the lower arm).

4. If you are looking at the original tree rather than the bootstrap consensus it is possible that you do have a branch that had no bootstrap support - I'm not sure what MEGA5 would show in that case (0% or no value) - but this is unlikely as any grouping.

If none of these explain your missing bootstrap then it is possible that you have discovered a bug in MEGA5 - there seem to be a few. I suspect another one is that in the bootstrap consensus tree MEGA5 doesn't collapse branches below your threshold value into polytomies.

Richard, thanks for some good comments here. An alternative way to view bootstrapping is as a random re-weighting procedure which shows how much a branch relies on particular characters. Individual characters are selected at random when constructing each bootstrap pseudoreplicate dataset, with each character represented from 0 to as many times as there are characters, but keeping a mean of one occurrence as in the original data (it is the variance about this mean, and particularly the proportion of sites that are not represented in a particular pseudoreplicate that gives differential support from different replicates). The number of times a character is represented in a bootstrap pseudoreplicate dataset is equivalent to a weighting on that character when analysing that dataset. If a branch in your dataset has robust support, with many characters supporting that split and few characters opposing it, then at least some of these characters will be included, some multiple times, in each pseudoreplicate and that branch will be well supported. If a split has few uncontested characters supporting it then it will be present in a low percentage of pseudoreplicates - which is our bootstrap support value.

Sorry about the long post - one last general point about bootstrapping which might be of interest. Bootstrapping fails to give an accurate measure of support for very recent splits. This is especially important to keep in mind for reconstructing phylogeographic gene-genealogies, where ancestral sequence alleles co-occur with their own descendent sequences. This is one reason why it is usually better to view gene-genealogies within populations as unrooted trees, or networks, rather than as rooted trees (the other reason is because if there is uncertainty about connections a network allows you to show all options and some measure of support for these - but can lead to very complex diagrams). Bootstrapping works by assessing character support in the presence of homoplasy. If you have phylogeographic data, for example from a coding gene, with no more than a handful of substitutions separating any two alleles, and few missing intermediates, then you may have very high confidence of the splits among these sequence alleles (or haplotypes if you prefer that much abused term) but very low bootstrap values. This is because there are 1 or few changes among adjacent alleles in the tree, and this one character will be absent from a high proportion of bootstrap pseudoreplicates. In a dataset of 100 characters you need at least 3 uncontested synapomorphies to generate a 95% bootstrap support - even though there may be little uncertainty about relationships with 1 or 2 uncontested supporting characters. Of course, to some degree you can address this problem with longer sequences but this will also split identical haplotypes into several similar ones. At the limit you can sequence whole genomes without resolving the issue. This is why the coalescent methods of statistical phylogeography provide better ways of analysing support for relationships in phylogeographic data.

Hi Michael and Richard,

I wonder if case 3 (basal branch problem) happens, is it OK to simply put the BS value on both the lower and upper "nodes (arms)"?

Also, what always bugs me is that, is it legit to re-root a tree after a tree is produced, by picking a robust clade, or by doing a midpoint rooting?

Although someone told me that topologically it shouldn't matter because it's just another way of presenting a tree, but would the BS values AFTER rerooting can still be trusted since usually a re-rooted tree shifts some of the values to the other edge of the branches they support?

Thanks,

Davin

Uncheck any cut-off of %BT, and it will show all %BT.

This is a question about the result displayed in MEGA5, not about the interpretation of the missing bootstrap value.

1. Paolo is right - in the tree explorer of MEGA5 click the toolbox icon (brings up the M5: Tree Options window), Choose the Branch tab, there is a tick box there for Hide values lower than x% - you choose the x value. The default option in MEGA5 however is that the tick box is clicked off (and default x=0 so even with the box ticked it will show bootstraps for all applicable branches by default). So if you haven't changed this the explanation is elsewhere.

2. Bootstraps measure support for splits between groups > 2 taxa on either side of the branch (taxa in the group vs those excluded). By definition there is no such thing as a bootstrap on a terminal branch.

3. As Richard says above, bootstrapping treats all trees as unrooted but we view these trees in MEGA5 with the basal branch bent like a hairpin (so that it actually looks like two branches, one on either side of a default midpoint root). The bootstrap value will only be seen on one side of this basal branch (on the lower arm).

4. If you are looking at the original tree rather than the bootstrap consensus it is possible that you do have a branch that had no bootstrap support - I'm not sure what MEGA5 would show in that case (0% or no value) - but this is unlikely as any grouping.

If none of these explain your missing bootstrap then it is possible that you have discovered a bug in MEGA5 - there seem to be a few. I suspect another one is that in the bootstrap consensus tree MEGA5 doesn't collapse branches below your threshold value into polytomies.

Richard, thanks for some good comments here. An alternative way to view bootstrapping is as a random re-weighting procedure which shows how much a branch relies on particular characters. Individual characters are selected at random when constructing each bootstrap pseudoreplicate dataset, with each character represented from 0 to as many times as there are characters, but keeping a mean of one occurrence as in the original data (it is the variance about this mean, and particularly the proportion of sites that are not represented in a particular pseudoreplicate that gives differential support from different replicates). The number of times a character is represented in a bootstrap pseudoreplicate dataset is equivalent to a weighting on that character when analysing that dataset. If a branch in your dataset has robust support, with many characters supporting that split and few characters opposing it, then at least some of these characters will be included, some multiple times, in each pseudoreplicate and that branch will be well supported. If a split has few uncontested characters supporting it then it will be present in a low percentage of pseudoreplicates - which is our bootstrap support value.

Sorry about the long post - one last general point about bootstrapping which might be of interest. Bootstrapping fails to give an accurate measure of support for very recent splits. This is especially important to keep in mind for reconstructing phylogeographic gene-genealogies, where ancestral sequence alleles co-occur with their own descendent sequences. This is one reason why it is usually better to view gene-genealogies within populations as unrooted trees, or networks, rather than as rooted trees (the other reason is because if there is uncertainty about connections a network allows you to show all options and some measure of support for these - but can lead to very complex diagrams). Bootstrapping works by assessing character support in the presence of homoplasy. If you have phylogeographic data, for example from a coding gene, with no more than a handful of substitutions separating any two alleles, and few missing intermediates, then you may have very high confidence of the splits among these sequence alleles (or haplotypes if you prefer that much abused term) but very low bootstrap values. This is because there are 1 or few changes among adjacent alleles in the tree, and this one character will be absent from a high proportion of bootstrap pseudoreplicates. In a dataset of 100 characters you need at least 3 uncontested synapomorphies to generate a 95% bootstrap support - even though there may be little uncertainty about relationships with 1 or 2 uncontested supporting characters. Of course, to some degree you can address this problem with longer sequences but this will also split identical haplotypes into several similar ones. At the limit you can sequence whole genomes without resolving the issue. This is why the coalescent methods of statistical phylogeography provide better ways of analysing support for relationships in phylogeographic data.

Why are some nodes in Mega5 NJ tree shown without boostrap values?. Available from: https://www.researchgate.net/post/Why_are_some_nodes_in_Mega5_NJ_tree_shown_without_boostrap_values [accessed Apr 13, 2017].