Bug#415418: components of phylip give wrong tree files
Andreas Tille and Peter Elo --
> I just want you make aware of a bug that was reported to the Debian
> bug tracking system.
>
> http://bugs.debian.org/415418
>
> Below you can find some more information and attached are the
> data files. Would you be able to verify this? It is a problem
> in Phylip itself or just the Debian packaged version?
>
> Kind regards and thanks for providing Phylip
>
> Andreas.
> ---------- Forwarded message ----------
> Date: Mon, 19 Mar 2007 14:51:13 +0100
> From: Elo Peter <elo@linux.vmri.hu>
> To: Andreas Tille <tillea@rki.de>
> Subject: Re: Bug#415418: components of phylip give wrong tree files
>
> >Thanks for the bug report. I have to admit that I do not use phylip
> >personally and thus I have to relay on a very detailed description
> >of your problem. At first I would like you to ask whether you could
> >upgrade aour phalip version currently residing in unstable. It is
> >not that the package of phylip itself is unstable but it will not
> >make its way into Etch because testing was frozen before the latest
> >upgrade of the package. If you could do an
>
> I hav updated to the unstable version, which have the same problem. The
> outtree has a weired "inside-out" look with the most similar sequences
> farther apart.
> I have attached a simple infie and the resulting outtree to show what is
> happening.
>
> Yours sincerely Peter Elo
> 5 18
> p32kb4/94- ASRQFFNYRR PPDGEEDVDY QAKNKWSLED VISYLQHIPK QVRKVILTSL
> p32_rus/85 AARQYFNYRR PPDGEEDVDY NAKSKWNLED VISYLQHIPK QVRKVILTSL
> OAV_p32/10 ARDQWYFPIR PSDGEHDTDV KVKKKWSLDT VLQFLQSSPK HIRQLLLTSL
> EDS_p24k/1 APLYEEPIVK RSDGEADQDR AIKHKWNIDD VLDFLMKVPE RTRKVVLISL
> snake_p32k VAEGNYLPRR PADGEADRDN RVRNRWSLEQ VLRTLERIPA RGRKLILTGL
>
> FGATLGLIID ALLGGPWGLT TRLLRLIVSL VPGGKILLLA LDGLGYFLGK
> FGATLGLIID ALLGGPWGLT TRLLRLIVSL VPGGKILLLA LDGLGYFLGK
> FGSLLGLILD TLFGGPWNLT SRLLRLIISV VPGGRILLTA LDGLGYFLGN
> FGTAVGAVID LMLGSPLGLT SKIIRAILRI IPGGWIILNT FDGLGYLLGK
> FGTAVGVVLD LLLGSPLNLT TRLVRLIVGF VPGGNLILNA LDGLGYLMSR
>
> -NNNPNLVAY DPDLIKFGTN IQRNINGRLT EDIVRAAEEQ LGGGFMRTLA
> -SNNPNLVAY DPDLIKFGTD IQKNINGRLT EDIVRAAEEQ LGGGFMRTLA
> -SANPIHLIE NPMMQAFGNS IQKQISPRLA EDIIKAADEQ IGGGFMRTIA
> -GQEVLQITY DPGFVELAKR VQSSIPPHTA EEIAAAADRQ LGGNTFTASL
> FPSNPLQITY DPGFQRLANS VQQNIPQGTA EALAHAAEQQ VGEGFARNLA
>
> ALLSAAASAG THLKIALPAI PLAVIKPFQR
> ALLSAAASAG THLKIALPAI PLAVIKPFQR
> SILSAAASAG THFTMALPAI PIAAVRPFMR
> AALLHAVFLR D--R------ ----------
> AAMSYLVGSA P--SAAPMAI PLALVRPFRP
> (p32_rus/85:0.02613,((snake_p32k:0.32827,EDS_p24k/1:0.70718):0.34711,
> OAV_p32/10:0.33825):0.24907,p32kb4/94-:0.02121);
Looking at this "wierd" "wrong" "nonsense tree" it looks fine to me.
Fitch and Proml output unrooted trees. The program defaults to rooting
these on sequence number 1. That does not change the topology or branch
lengths of the unrooted tree but can result in a startling tree if one
thinks of it a rooted tree. If Peter were to choose a more reasonable
outgroup, or else just look only at the unrooted shape of the tree,
would he find anything wrong with it? One way to root the tree is to
use the M (Midpoint rooting) option of Retree.
If he still finds a problem I can chase it, but at this stage I don't
think there is any.
Joe
----
Joe Felsenstein joe@gs.washington.edu
Department of Genome Sciences and Department of Biology,
University of Washington, Box 355065, Seattle, WA 98195-5065 USA
Reply to: