Because ClustalW/X is not a phylogeny software, it's an alignment package. Clustal should never be used to give you an accurate phylogenetic tree, it's there to give you an alignment and the tree is used to guide this alignment.

On the other hand, Phylip is a phylogenetic program that can be used to reliably give you a tree. As Diego pointed out, the matrices are different and you don't know or have control on all the features of the bootstrap in Clustal, while in Phylip you are able to change all possible parameters.

I do not know how ClustalX does the bootstraping. Bootstrapping has a random component but at least in my hands the results are virtually identical between runs both in Phylip and ClustalX but different between them.

I guess the distance/similarity matrices are different, thus the trees should be different.

The only reason that I can think of is that the random number generator is different and 111 seed leads to different random numbers generation by both the methods.

This can be validated by the fact that in Phylip the seed has to have a particular form

"The seed should be an integer between 1 and 2^32-3 (which is 4,294,967,293), and should be of form 4n+1"

http://evolution.genetics.washington.edu/phylip/doc/main.html

However, for clustalw there is no such criteria.

On a different note if the trees vary a lot based upon the seed, it would reflect in the low support values for the branches.

Because ClustalW/X is not a phylogeny software, it's an alignment package. Clustal should never be used to give you an accurate phylogenetic tree, it's there to give you an alignment and the tree is used to guide this alignment.

On the other hand, Phylip is a phylogenetic program that can be used to reliably give you a tree. As Diego pointed out, the matrices are different and you don't know or have control on all the features of the bootstrap in Clustal, while in Phylip you are able to change all possible parameters.

It is not clear from your question whether you are using the same distance calculations and gap treatment etc. for both programs. There are also different flavours of Neighbour-joining and input ordering etc. can effect results. I'm not sure if Phylip and Clustal are using exactly the same NJ algorithm. Have you tried making the tree with Phylip using the distance matrix produced by ClustalX (and constraining input order)? Paulo is right, though. Clustal is pretty good for quick, convenient trees when you only care about well-supported relationships but if you are doing any serious phylogenetics, you should use some dedicated phylogenetics software.

@Daniel Struck· The trees are also different without bootstraping so I guess that as Diego pointed the distance matrix is different. I need to find out why. Maybe they use different substitution matrices to obtain them.

Also, how different are they? You can use Robinson-Foulds distance to quantify the amount of difference among bootstrap replicates vs. the distances between the two topologies.

Thanks you all for the answers. If I choose the same substitutions matrices the trees from clustal and phylip are the same

By the way, i was not referring to clustal output trees generated along to the alignments (.dnd files) but to the N-J trees that one can generate with ClustalX from already made alignments -fed as input.

Keep in mind too, that Neighbor-Joining is about as simplistic a phylogenetic analysis as one can do, and one that has been historically discredited as a valid means of inferring evolutionary relationships. NJ trees persist because they are simple to understand mathematically, and are easy and fast to compute. But the fact remains they are very poor performers in deriving evolutionary relationships.

You would do much better using a true evolutionary model based method such as Parsimony, Maximum Likelihood, or Bayesian based method. These have all been shown to be significantly superior to simple distance-based clustering methods.

Neighbor joining is not necessarily "weak and worthless". In my experience, when incorrect trees are made, it is almost always the fault of the data input, or the parameters used within a phylogenetic reconstruction method, and not the method itself. In this case, further comments by the original poster, Pedro Reche, have indicated that it was using different models of evolution (different substitution matrices) which resulted in the different trees. This type of information in itself can be useful. Getting the right tree, is not the only thing phylogeny reconstruction is used for. It is also useful for obtaining information about the evolutionary process, such as the ratio of transitions to transversions, selection pressure on the gene, population sizes, etc. It can often be more informative to explore the data by building ten NJ trees with different parameters (each tree taking a fraction of a second to build) than to uee what is supposedly the most sophisticated computer model available to build one "best tree" (perhaps waiting an hour or days for the result) and not understanding which aspects of the data or analysis were most important for inferring the phylogeny.

I agree with Brian. NJ is still very useful and will consistently give the right tree with good data. Furthermore, it is much easier to spot biases. I have found much more problem with ML methods, where biases due to flawed assumptions of the model and/or erroneous data can be really hard to spot/understand unless you are an expert. Parsimony trees can also suffer because they toss out so much data. The best policy IMO is usually to do a NJ, MP and ML tree, then compare and contrast to spot potential errors.

I have used GOOGLE+ and FIgShare to discuss a couple of points in phylogenetics here: https://plus.google.com/104222550058767304622/posts/NybbBh5yKHk and here http://figshare.com/articles/Saturation_with_mutations_by_Transition_Transversion_analysis/89815