While running fossil-calibrated molecular-clocks analysis in BEAST, I keep receiving some strange numbers as node ages. I input the numbers in millions of years (see Fig.1) and yet I am receiving mean node ages in numbers like 0.899, 0.371 etc. (see Fig.2).
I am basically rerunning published time-calibrated pyhlogenetic analysis after inclusion of new OTUs. Therefore, I have some idea how results should look like and it seems that node ages are dated relatively (in sense of their relative position) correctlly, i.e. in accordance to that published study.
In other words, the tree itself seems to be fine but my time axis looks like this (Fig.3), while it should look like this (Fig.4, btw I received this picture with correct units on the axis by forcing the root age in FigTree to be in accordance to the published study mentioned above, which is a step I wish to avoid).
I bet this will be some minor issue but perhaps someone will share their experience and save me a bit of time. Does anyone have any ideas?
If I remember BEAST correctly, after loading your tree you must click "node labels" and apply "heights". This will provide you with the times of divergence.
Also, not sure how much optimization you have done, but those ESS values do not look very good. Have you tried different combinations of priors/models perhaps in different parts of your dataset (i.e. for example excluding genes with saturated divergence)?
Dear José, thanks for answer. Unfortunatelly, it is not the case (and it does not work, I tried it to be 100% sure, of course). I am pretty sure that the issue is not matter of visualization and thus it cannot be resolved in FigTree. I think that it's cause is somewhere in Priors setting stage in BEAUti. At the moment, I suspect "treeModel.rootHeight" for being responsible but changing it leads either to error or no change. Also, don't worry about ESS values. That issue was already resolved by increasing number of MCMC generations.
Hi Jan, it's likely that your priors for TMCRA were not used or your settings were not write to .xml file. Please have a check for you xml file or try to use other version BEAST to exclude such possibility. It appears to me that BEAST v1.7.4 and v1.8.4 are stable.
Dear Chengmin, thanks for your suggestion. However, my .xml file includes "tmcra" priors despite using v. 1.10.4. Nevertheless, it is true that there are at least 3 differences between my procedure and the procedure followed in the published study that I am trying to reproduce:
(1) They used the BEAST v. 1.5.4, while I used v. 1.10.4.
(2) They used linearized time-constrained user-defined starting tree constructed in r8s based on the ML tree constructed in RAxML. My user-defined starting tree was constructed in IqTree. The topology of both is identical which is why I do not expect this difference to be the cause (I may be wrong, of course).
(3) They set probability distribution to "varied (uniform, gamma and truncated normal)" for root node calibration prior and to uniform for all internal calibration points. I was unable to reproduce this setting, receiving infamous "The initial model is invalid because state has a zero probability" error. On the other hand, I was able to run the analysis when changing all tmrca priors to normal truncated probability distribution (adjusting input numbers accordingly, of course, i.e. changing the upper and lower limits to means, standard deviations and upper and lower limits to truncate it).
To be complete, the fourth difference is that I added new OTUs which is the reason why I rerun the published analysis in the first place. I think I will try to rerun the analysis in the v. 1.5.4, if I manage to get it (difference 1). Eventually, I will try to figure out how to run the analysis with uniform priors (difference 3). If both fail to resolve the issue, I will just switch to some other software (maybe BEAST2 would be worth of trial) which I am more familiar with (MrBayes). If someone sees some problem or/and possible cause in details I've just provided, I will be happy to hear it.
The tmrca looks like the average number of substitutions in one million - in other words the branch lengths of the tree branches. Do they make any sense if you multiply the values by the number of years since the fossil origin?
Dear Patrice, no they do not. I think the numbers are average numbers of substitutions per site. It seems that input temporal data are not incorporated in the computations (although they are present in xml file), as Chengmin suggested earlier. I have also tried to force root height according to the results of that published study using *.rootHeight priors. However, those attempts ended in error. I've just switched to BEAST2 so soon we will see how that works. Thanks for sharing your ideas though!
- Badges
- Science method
- Similar topics
- Biological Science
- Evolutionary Biology
- Phylogenetics
- Phylogenetic Analysis