[R-sig-phylo] Phyloinformatics Summer of Code 2011 - Call for student applications
*** Please disseminate widely at your local institutions, ***
*** including posting to message and job boards, so that ***
*** we reach as many interested students as possible. ***
PHYLOINFORMATICS SUMMER OF CODE 2011
http://informatics.nescent.org/wiki/Phyloinformatics_Summer_of_Code_2011
The Phyloinformatics Summer of Code program provides a unique
opportunity for undergraduate, masters, and PhD students to obtain
hands-on experience writing and extending open-source software for
evolutionary informatics under the mentorship of experienced
developers from around the world. The program is the participation of
the US National Evolutionary Synthesis Center (NESCent) as a mentoring
organization in the Google Summer of Code(tm) (http://code.google.com/soc/
).
Students in the program will receive a stipend from Google (and
possibly more importantly, a T-shirt solely available to successful
participants), and may work from their home, or home institution, for
the duration of the 3 month program. Each student will have at least
one dedicated mentor to show them the ropes and help them complete
their project.
NESCent is particularly targeting students interested in both
evolutionary biology and software development. Initial project ideas
are listed on the website. These range from visualizing viral
epidemics to 3D protein structure evolution, rich annotation for
TreeBASE content, exposing phenotype observations to the Encyclopedia
of Life, to enhancing R packages for phylogenetic analysis. All
project ideas are flexible and many can be adjusted in scope to match
the skills of the student. We also welcome novel project ideas that
dovetail with student interests.
TO APPLY: Apply online at the Google Summer of Code website (http://socghop.appspot.com/
), where you will also find GSoC program rules and eligibility
requirements. Each organization has a slightly different application
format, and ours is at http://bit.ly/PhyloSoC2011-apptemplate. The 12-
day application period for students opens on Monday, March 28th, and
runs through Friday, April 8th, 2011.
INQUIRIES: phylosoc {at} nescent {dot} org. We strongly encourage all
interested students to get in touch with us with their ideas as early
on as possible. Working closely with potential mentors to develop your
project proposal greatly increases your chance for acceptance. Do not
underestimate the amount of time it takes to develop a competitive
proposal.
2011 NESCent Phyloinformatics Summer of Code:
http://informatics.nescent.org/wiki/Phyloinformatics_Summer_of_Code_2011
Google Summer of Code FAQ:
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/faqs
-
Karen Cranston and Hilmar Lapp
National Evolutionary Synthesis Center
http://nescent.org
___
R-sig-phylo mailing list
R-sig-phylo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Pagel's lambda greater than one?
If I am not mistaken, Dan's and Liam's emails seem to describe how maximum values of Pagel's lambda can be calculated for each phylogeny. In ultrametric trees, maximum lambda would correspond to max(covariance in phylogeny)/variance For instance, if a phylogeny has a variance of 100 and the maximum covariance in the vcv matrix is 80 (i.e., the closest relatives in the phylogeny share 80% of their evolutionary history), then the condition to calculate lambda would be maxlambda*max(cov(tree)) < var(tree) maxlambda*80 < 100 maxlambda < 100/80 maxlambda < 1.25 In essence, a maximum lambda of 1 generalizes the method to any ultrametric trees (I am not entirely sure what happens with trees that are not ultrametric), but lambda apparently can be larger than 1. Is this right? Enrico 26/3/11 1:09 a.m., Liam J. Revell escribió: Hi Dan, list. lambda>1 doesn't necessarily imply covariances>variances. This will depend on the shape of the tree. For instance in a tree with very long terminal edges, lambda can theoretically be much larger than 1.0 without implying that the expected covariances among species are greater than the expected variances. Of course, if lambda results in covariances>variances then the likelihood equation for lambda becomes undefined. lambda>1 might suggest that the rate of evolution for the trait of interest (or the residual error in the model, in the case of lambda fit using gls(...,correlation=corPagel(...)) is high at the root of the tree and decreases towards the tips. - Liam -- Enrico L. Rezende Departament de Genètica i de Microbiologia Facultat de Biociències, Edifici Cn Universitat Autònoma de Barcelona 08193 Bellaterra (Barcelona) SPAIN Telephone: +34 93 581 4705 Fax: +34 93 581 2387 E-mail:enrico.reze...@uab.cat ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] reading nexus file from treebase?
Hi Mark, Brian and others, Mark Holder wrote on 25/03/2011 23:12: Hi all, Adding a command skipping feature to ape, might make it a good bit more robust to some of the weird files that are out there. I'm afraid that I'm not familiar enough with the code to suggest where those changes should go. It's done. I've also fixed a bug in write.nexus() at the same occasion. I've just submitted ape 2.7-1 to CRAN. For those who'd like to try it right now, I've updated svn and uploaded the sources here: http://ape.mpl.ird.fr/ape_2.7-1.tar.gz Cheers, Emmanuel The NEXUS standard indicates that parsers should skip commands that they don't understand. This can lead to problems (if there were multiple taxa blocks in the same file and you ignore the LINK commands, for instance). But in many cases, skipping these commands will work fine. Skipping a command simply entails reading NEXUS tokens until the token; is encountered. The tokenization rules are spec ( http://www.ncbi.nlm.nih.gov/pubmed/11975335 ). Mesquite also occasionally uses a BLOCKID command (in pretty much any block). all the best, Mark On Mar 25, 2011, at 10:58 AM, Brian O'Meara wrote: TITLE and LINK are used by Mesquite but not many other Nexus-reading programs (TITLE appears as a future reserved command name in the Maddison et al. (1997) nexus specification but I don't see LINK there). Brian ___ Brian O'Meara Assistant Professor Dept. of Ecology & Evolutionary Biology U. of Tennessee, Knoxville http://www.brianomeara.info Students wanted: Applications due Dec. 15, annually Postdoc collaborators wanted: Check NIMBioS' website Funding wanted: Want to collaborate on a grant? On Fri, Mar 25, 2011 at 11:28 AM, Hilmar Lapp wrote: Thanks for tracking this down, Emmanuel. I'm forwarding this to the TreeBASE developers list for consideration. BTW the phylobase implementation uses NCL (NEXUS Class Library, in C++) for parsing NEXUS. Given the difference, probably ape does not? -hilmar [-- cut --] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Possible Error in prop.part() ?
David, Your example works correctly for me. A bug was fixed in prop.part() in ape 2.7 but this apparently affected some unrooted trees, while your trees are clearly rooted. Best, Emmanuel David Bapst wrote on 26/03/2011 04:32: Hello all, I was using prop.part() to identify nodes shared between several topologies, when I discovered a strange error, where prop.part() was underestimating the number of partitions found in common. I was able to fix the error for some comparisons by outputting the trees as Newick strings and reading them back in with read.tree(text=write.tree()). However, this didn't work for all topologies, which actually allowed me to reproduce the error for you all, using the code below. tree1 and tree2 have five shared nodes, but prop.part() only reports two partitions as being found in common. prop.clades() seems to report the correct number. require(ape) tree1<-read.tree(text="(((TAXt9,TAXt4),(((TAXt6,TAXt3),TAXt13),((TAXt1,(TAXt12,TAXt14)),TAXt11))),TAXt7);") tree2<-read.tree(text="(((TAXt6,((TAXt13,TAXt3),(TAXt1,(TAXt12,TAXt14,(TAXt11,(TAXt9,TAXt4))),TAXt7);") prop.part(tree1,tree2) prop.clades(tree1,tree2) For this particular example, it turns out that prop.part() correctly estimated the number of partitions prior to me applying the read.tree() fix. But I'm doing this over a large number of pairs, so I need a solution that works for all. I'm using R v2.12.2 and ape v2.6-3. I haven't updated to 2.7 since I use read.nexus() quite a bit; let me know if it is reproducible in that version. -Dave -- Emmanuel Paradis IRD, Jakarta, Indonesia http://ape.mpl.ird.fr/ ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
