plot ancestral states error

[Mario Mairal]

Hello I am new in BioGeoBears,

I am running an analysis with 11 areas and 32 lineages.

I´ve got problems plotting the ancestral states (DIVALIKE). When I try to run #states, this error appears:

Error in marprobs[leftright_nodes_matrix[, 2], ] : 

  subscript out of bounds 

may be a typical beginner's question...

Could anyone help me with this, please? I am thankful for any advice!

Mario 

[Nick Matzke]

That's actually a new error, if you're pretty sure you've done all the source() commands and run the example script commands in order, then send me your inputs and I can try to see what the issue is.

Cheers,

Nick

--
You received this message because you are subscribed to the Google Groups "BioGeoBEARS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biogeobears...@googlegroups.com.
To post to this group, send email to bioge...@googlegroups.com.
Visit this group at http://groups.google.com/group/biogeobears.
To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/d0ce81de-535e-4de9-9812-d12d7f824770%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Matzke]

Mario sent me his dataset, and I was able to replicate the error, which occurred because the result of the optimx function was coming out as empty after the optimization had finished.  Strangely, though, as soon as I modified the function to print the optimx output to screen, the error went away, and now all the errors/plots work find.  

My suspicion is that this means there is something about optimx, perhaps internal C code, which means that results weren't being transferred to the output quite instantaneously, but having the print statement gives sufficient time for it to catch up.  I have very rarely experience similar weirdness with R interactions with C, FORTRAN, etc.

Anyway, I've posted the update to PhyloWiki.

Mario, or anyone else, if you still get the error, let me know.

PS: I've found that, sometimes, copying/pasting large chunks of code into e.g. Mac Terminal can cause errors, due either to some kind of buffer limit on how much can be pasted in, or some command that is a little bit slow -- e.g. sourcing remote files.  E.g.:

===========

# default here is your home dire> source("http://phylo.wsource(com/local--files/el_v1.R")rs/BioGeoBEARS_univ_mod 

Error in file(filename, "r", encoding = encoding) : 

  cannot open the connection

In addition: Warning message:

In file(filename, "r", encoding = encoding) :

  unable to resolve 'phylo.wsource(com'

===========

...if you see something like this (and sometimes it goes by fast, so scroll up), a command didn't fully paste in, and caused an error, so you have to go back and paste things in chunk-by-chunk.

One alternative is to run your script from the Terminal with e.g.:

R CMD BATCH scriptname.R

Cheers!

Nick

[Mario Mairal]

Thank you very much Nick! very useful!

[Olympia P.]

Hello Nick,

I have also encountered the following error, but while running DEC+J:

Error in marprobs[leftright_nodes_matrix[, 2], ] : 

  subscript out of bounds

In addition to this error message I also received one other:

[1] NaN NaN NaN NaN NaN NaN NaN NaN

Error in calc_loglike_sp(tip_condlikes_of_data_on_each_state = tip_condlikes_of_data_on_each_state,

Sorry, I am still new to BioGeoBEARS but I did manage to run the example script. Thank you very much for your time.

-Olympia

[Nick Matzke]

Hi,

If you still get the error, after very carefully making sure you've run the source() commands as instructed on PhyloWiki, email me your files and script.

Cheers!

Nick

[Olympia P.]

Hello Nick,

Thank you so much for your reply. Unfortunately the errors are still there, I hope my files are okay, I have attached them. Thank you for your help.

-Olympia

[Nick Matzke]

Hi Olympia, it all ran fine for me, files and script attached.

I should say -- this looks like a parsimony tree with post-hoc time scaling and thus many ultra-short branches.  Such trees are still fairly common but I think within a few years they won't be usable in publications, because they are likely not a realistic estimate of divergence times or branch lengths.  In this particular case it probably won't matter much as d and e are estimated at 0 -- as these are the only anagenetic, continuous-time parameters, when they are 0, then branch length is irrelevant. On the other hand, with a realistic tree, you might get different estimates (although probably not, as all the tips are single-areas, which tends to support +J models).

My preferred method for time-scaling is BEASTmasteR and Beast2, there are other options though:

http://phylo.wikidot.com/beastmaster

Cheers,

Nick

Visit this group at https://groups.google.com/group/biogeobears.

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/71198bb4-0c00-484c-9908-45e175d1c0da%40googlegroups.com.

[Olympia P.]

Hello Nick,

Thank you so much for your help!! Really appreciate all the information and the BEASTmasteR recommendation, thanks again for taking the time!

-Olympia

[James Kitson]

Hello all,

Was there a specific solution for Olympia's error above? I've updated all my libraries, and run all the source() commands and the rest of the code chunk-by-chunk but still the same error. The only real differences from the original sample script are the input files.

Many Thanks,

James

[Nick Matzke]

Hi- that's weird, for Olympia the issue seemed fixed when I ran the script with all of the source commands- keeping in mind that the One True List of updates is the example script on the main phylowiki biogeobears page, and older files/scripts won't necessarily have them all.  If you email me your files I can double check. Cheers! Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/709b5a90-83ab-4fe2-aafa-a70fc5d73e22%40googlegroups.com.

[James Kitson]

Hi Nick,

I've attached the files. A bit of background in case this helps; I've performed the dating analysis in MrBayes so the tree is ultrametric but the actual node ages are stored in a separate output file i.e. the branch lengths will look like they are scaled in substitutions. There are some polytomies which I resolved using multi2di(my.tree, random=TRUE) and I've given the new branch lengths a very short length that is still longer than the min_branchlength that would cause BioGeoBEARS to interpret them as a hook. The following code chunk will get you from the attached tree to the tree that fails to plot.

### read in the resolved tree

tree.resolve<-read.nexus("resolved_tree.nex")

### give zero length branches an arbitrarily short length that is higher than the min branch length for BioGeoBEARS

### this prevents BioGeoBEARS from interpreting the ultra short branch as a direct ancestor.

tree.resolve$edge.length<-ifelse(tree.resolve$edge.length==0,0.00001,tree.resolve$edge.length)

Many Thanks,

James

To unsubscribe from this group and stop receiving emails from it, send an email to biogeobears+unsubscribe@googlegroups.com.

[Nick Matzke]

Thanks, I'll take a look...

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/709b5a90-83ab-4fe2-aafa-a70fc5d73e22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "BioGeoBEARS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biogeobears...@googlegroups.com.
To post to this group, send email to bioge...@googlegroups.com.
Visit this group at https://groups.google.com/group/biogeobears.

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/9a9332e3-5122-4d51-a2f9-2219ba08d673%40googlegroups.com.

[Nick Matzke]

Hi,

It worked fine for me, *BUT* I had to:

1. I made sure the geography file was formatted correctly (compare geog.data to your geography file)

2. I made sure your NEXUS file was edited as you coded, AND converted to Newick AND saved as Newick. E.g.:

========================

library(ape)

wd = "/drives/Dropbox/_njm/__packages/BioGeoBEARS_setup/z_help/James_Kitson/"

setwd(wd)

nexfn = "resolved_tree.nex"

tr = read.nexus(nexfn)

### read in the resolved tree

tree.resolve<-read.nexus("resolved_tree.nex")

### give zero length branches an arbitrarily short length 

# that is higher than the min branch length for BioGeoBEARS

### this prevents BioGeoBEARS from interpreting the ultra 

# short branch as a direct ancestor.

tr = tree.resolve

tr$edge.length<-ifelse(test=tree.resolve$edge.length==0, yes=0.00001, no=tree.resolve$edge.length)

write.tree(tr, file="tree.newick")

========================

With those files, and the current script/source files, it seems to work, script, inputs/outputs attached.  

Example input files are here:

http://phylo.wikidot.com/biogeobears#links_to_files

If you figure out what caused your issue, let me know...

Cheers!

Nick

[Nick Matzke]

Also, loose thought -- I am dubious about majority-rules trees in a dated-tree context. What does a polytomy even mean in a dated tree?  What does the date of a polytomy node represent?  The BEAST MCC trees make more sense to me, being one of the sampled tree topologies which are fully resolved...

Cheers,

Nick

[James Kitson]

It's a good point. I've always felt a little unsure of MCC trees simply because I think a polytomy is a more obvious way of showing the uncertainty in your data (or it may even be real i.e. speciation at time scales below the resolution of your dataset) but I guess for a biogeographic analysis, why not show the most credible scenario across the sampled trees?

Many Thanks for pointing out the formatting errors.

James

To unsubscribe from this group and stop receiving emails from it, send an email to biogeobears+unsubscribe@googlegroups.com.

To post to this group, send email to bioge...@googlegroups.com.
Visit this group at https://groups.google.com/group/biogeobears.
To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/709b5a90-83ab-4fe2-aafa-a70fc5d73e22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.