Trouble after recent October 10th Github update

[Chauncey Gadek]

Hi all,

I am having issues running my BioGeo Bears scripts that have all worked until the 10/10/18 update. I have updated all packages and followed the new installation/setup/sourcing script that Nick posted (including setting $optimx = "GenSA") but I continually get the following error when running all models:

Error in rcpp_calc_anclikes_sp_COOweights_faster(Rcpp_leftprobs = tmpca_1,  : unused arguments (m = m, m_null_range = include_null_range, jts_matrix = jts_matrix)

Should I still be sourcing cladoRccp? Either way, this error appears.

If anyone has any insight into this issue, I would greatly appreciate their wisdom. I'm sure it is staring me in the face.

Best,

Chauncey Gadek

[Nick Matzke]

Hi -- this issue should go away permanently, if you install the updated cladoRcpp from CRAN:

install.packages("cladoRcpp")

Check that the version installed is version 0.15:

packageVersion(pkg="cladoRcpp")

# [1] ‘0.15’

Binaries should be available for all Windows/Mac systems now, so it should install easily: 

https://cran.r-project.org/web/packages/cladoRcpp/index.html

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 https://groups.google.com/group/biogeobears.
To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/29c65738-9d48-4230-97e2-9df609248717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chauncey Gadek]

Thanks Nick! 

I had updated to version 0.15 but a fresh install worked.

However, now the models (time stratified, *) are giving me a fatal error:

FATAL ERROR IN calc_loglike_sp_stratified(). grand_total_likelihood=NA.

These rows of 'all_relative_probs_of_each_state' had NAs:

This did not occur with optimx, but GenSA dislikes my constraints. Could this mean that optimx was not giving me a reliable result?

Thanks,

Chauncey 

You received this message because you are subscribed to a topic in the Google Groups "BioGeoBEARS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/biogeobears/2f9etrphhmg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAJdu7BCNDFzCZQrT1pJMNbFYUod3jsQNyJr7hmjfABboQpJ5ZQ%40mail.gmail.com.

[Nick Matzke]

I saw an error like this recently, when using use_optimx=TRUE, after I installed everything fresh (including the new optimx) -- but it went away when I switched to use_optimx="GenSA".

However, now I get no errors running it either way, on either optimx or GenSA, and whether I have a non-stratified analysis, a time-stratified analysis with changing dispersal multipliers, or a time-stratified analysis with changing areas allowed.

So, I'm not sure what is going on. It could be some conflict between installed packages and old versions cached somewhere, so it may be that closing/opening R and re-installing the packages fixes the issue.

If you get the problem happening repeatably, please send me all the input files and script, and I will see if I can figure out the exact cause.  An error like this looks like the result of the optimization is getting mis-read, e.g. if the log-likelihood was being misread as a parameter value, which would create a negative rate parameter, which would create a NaN error.  So, I figured this was some change in optimx since that was updated on September 30 -- but now I can't replicate the error.

The BioGeoBEARS code hasn't changed from recent months, it's just been moved to GitHub, so it's probably not that either.

Cheers!

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/F54B234F-D360-4FB1-8E73-7520FE9A9664%40gmail.com.

[sknu2003]

I also have issues running my BioGeoBEARS scripts after the update.

I checked the version of 'cladoRcpp'

> packageVersion(pkg="cladoRcpp")
[1] ‘0.15’

And this appears to be the right version.

But I continue to get this error:

Error in .Call("cpp_areas_list_to_states_list", as.integer(R_areas_indices),  :
  "cpp_areas_list_to_states_list" not available for .Call() for package "cladoRcpp"

After I try and run the first

if (runslow) loop (line 442-455 in my attached R-script)

I also trying re-starting R, and installing the cladoRcpp again, but I continue to get the error message above.

I am not sure what I have missed.

I am attaching my R-script and the input-files associated in a zip-file.

Thanks in advance for any help on this,

Steen

[Nick Matzke]

Hi Steen -- that's a weird one -- thanks for the detailed message, I will take a look.

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 https://groups.google.com/group/biogeobears.

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/99b66f5f-1fc5-454a-96ed-ec4d85bb34f4%40googlegroups.com.

[Nick Matzke]

Hi Steen,

Your code worked fine for me -- I wonder if it might just be that you have an old version of R?

Maybe try this:

R.Version()$version.string

...and tell me what you get.  Then, if it is older than "R version 3.5.1 (2018-07-02)", maybe try updating R, then reinstalling the packages.

Thanks!

Nick

PS: Attaching the script with some minor edits/tips, labeled with 2018-10-19_NJM.

Cheers!

Nick

[sknu2003]

Thanks for looking at my code, and modifying it. Yes. I was running an old version of R v.3.3.3.

I tried R v3.5.1 in Rstudio but now I got this error message:

Error in BioGeoBEARS_model_object@params_table$est[free_params_TF] <- params :
  replacement has length zero
In addition: Warning message:
In (function (npt = min(n + 2L, 2L * n), rhobeg = NA, rhoend = NA,  :
  unused control arguments ignored

Right after I have tried the if runslow part again.

To be able to run v3.5.1 I switched to ubuntu 18.

If I check my version in Rstudio I get this:

> version
               _                          
platform       x86_64-pc-linux-gnu        
arch           x86_64                     
os             linux-gnu                  
system         x86_64, linux-gnu          
status                                    
major          3                          
minor          5.1                        
year           2018                       
month          07                         
day            02                         
svn rev        74947                      
language       R                          
version.string R version 3.5.1 (2018-07-02)
nickname       Feather Spray   

I am grateful for any help on this.

Thanks

On Monday, October 15, 2018 at 10:09:22 PM UTC+2, Chauncey Gadek wrote:

[Nick Matzke]

Hmm, that error looks like it would be due to having the old version of BioGeoBEARS (0.21), rather than the GitHub version (1.1)...so try updating with the GitHub one...

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 https://groups.google.com/group/biogeobears.

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/ebc22d6f-14cc-4435-9a1f-196f0ff2e7f7%40googlegroups.com.

[sknu2003]

Thanks. Yes . I was running an older version.

I am not sure why I ended up with an older installation.

Perhaps because I was running all my code in one go in R-studio.

I added this part:

devtools::install_github(repo='nmatzke/BioGeoBEARS', force=TRUE)
packageVersion(pkg="BioGeoBEARS")

And ran this separately before continuing with the rest of the code.

Before reading in all my input files, I checked the version of BioGeoBEARS was 1.1.

And this solved my problem.

When running this line on its own

devtools::install_github(repo='nmatzke/BioGeoBEARS', force=TRUE)

I get queried to choose from 4 options. I think this part gets lost in all the rest of the code, if I run all my code in one go. When I provide a number for this option, the correct version of BioGeoBEARS is read in (v. 1.1). If I just run all my code in one go, this parts disappears, and I ended up with no BioGeoBEARS or an older version of BioGeoBEARS read in.

One last thing. I think I might be getting different LnL -scores with the new version of BioGeoBEARS, even though I am using the very same input files.

Before the updated BioGeoBEARS version I tested my topology with first 64 states/ranges, and then tested it again with 39 states/ranges - after having removed non-possible range-cobinations. Before the update, this gave me better LnL values for a test with 39 states/ranges. Now it is the other way round, and I get slightly worse LnL scores for the 39 states test, compared with better LnL values on my test on 64 states.

I cannot replicate this, as I do not know how to install the previous version of BioGeoBEARS and get it running. It could also just be that the new version of BioGeoBEARS is more precise in its calculations than the older version was. And that the LnL values I got before were incorrect.

On Monday, October 15, 2018 at 10:09:22 PM UTC+2, Chauncey Gadek wrote:

[selin...@evobio.eu]

Adding to this observation because I was just fighting with it: even if you install BGB 1.1 and the package version shows 1.1 it still won't work unless you actually restart R and do library(BioGeoBEARS) again. (I think in my case it had installed the old version first and then the new one; but a lot of dependencies were still coined on the old one as long as I left R open).

Something else that I noticed - if you suddenly have trouble with the tipranges command after uploading both your tree file and your geography file, check that the ending of the tree file is .newick . For some reason mine were all .tre (it worked previously before the new R version came out). Once I changed the file ending to .newick (without altering the file in any way), the errors disappeared.

[Nick Matzke]

On Wed, Oct 24, 2018 at 10:51 PM sknu2003 <skn...@aucklanduni.ac.nz> wrote:

Thanks. Yes . I was running an older version.

I am not sure why I ended up with an older installation.

Perhaps because I was running all my code in one go in R-studio.

I added this part:

devtools::install_github(repo='nmatzke/BioGeoBEARS', force=TRUE)
packageVersion(pkg="BioGeoBEARS")

And ran this separately before continuing with the rest of the code.

Before reading in all my input files, I checked the version of BioGeoBEARS was 1.1.

And this solved my problem.

When running this line on its own

devtools::install_github(repo='nmatzke/BioGeoBEARS', force=TRUE)

I get queried to choose from 4 options. I think this part gets lost in all the rest of the code, if I run all my code in one go. When I provide a number for this option, the correct version of BioGeoBEARS is read in (v. 1.1). If I just run all my code in one go, this parts disappears, and I ended up with no BioGeoBEARS or an older version of BioGeoBEARS read in.

One last thing. I think I might be getting different LnL -scores with the new version of BioGeoBEARS, even though I am using the very same input files.

Before the updated BioGeoBEARS version I tested my topology with first 64 states/ranges, and then tested it again with 39 states/ranges - after having removed non-possible range-cobinations. Before the update, this gave me better LnL values for a test with 39 states/ranges. Now it is the other way round, and I get slightly worse LnL scores for the 39 states test, compared with better LnL values on my test on 64 states.

I cannot replicate this, as I do not know how to install the previous version of BioGeoBEARS and get it running. It could also just be that the new version of BioGeoBEARS is more precise in its calculations than the older version was. And that the LnL values I got before were incorrect.

Hi -- re: package installations -- on rare occasions, I have noticed that it is possible to have 2 conflicting installations, in different "lib" directories.  Generally it is best to uninstall them both, and then install the one you want fresh to whatever the default "lib" directory is (so that you don't have to specify the "lib" directory).

These are some tools that help you find/remove packages:

# Library, then un-library, a package:

library(sp)

detach("package:sp")

# Find where a package is installed:

find.package(package="cladoRcpp")

# Check the version:

packageVersion("cladoRcpp")

# Remove packages installed in different places:

remove.packages(pkgs="Rcpp", lib="/Library/Frameworks/R.framework/Resources/library/")

remove.packages(pkgs="Rcpp", lib="/Users/nickm/Library/R/2.10/library/")

# See a list of all installed packages (allegedly at least):

installed.packages()

Re: different likelihoods, that really should not happen as the likelihood code hasn't been changed at all. However, changing any of these things could change the likelihoods:

- the tree

- the data

- the optimization routine, at least in more difficult problems (e.g. optimx vs GenSA), if one finds the optimum likelihood and the other doesn't

- the other input files (area adjacency, dispersal multipliers etc.)

- or changing the script to comment one in/out one of the input files

On the other hand, it is possible something somehow got screwed up on my end, although all the basic checks I have run so far come back the same as before. I am working on checking some more complex cases (changing state spaces through time etc.)

Cheers!

Nick

 

On Monday, October 15, 2018 at 10:09:22 PM UTC+2, Chauncey Gadek wrote:

Hi all,

I am having issues running my BioGeo Bears scripts that have all worked until the 10/10/18 update. I have updated all packages and followed the new installation/setup/sourcing script that Nick posted (including setting $optimx = "GenSA") but I continually get the following error when running all models:

Error in rcpp_calc_anclikes_sp_COOweights_faster(Rcpp_leftprobs = tmpca_1,  : unused arguments (m = m, m_null_range = include_null_range, jts_matrix = jts_matrix)

Should I still be sourcing cladoRccp? Either way, this error appears.

If anyone has any insight into this issue, I would greatly appreciate their wisdom. I'm sure it is staring me in the face.

Best,

Chauncey Gadek

--
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/5988384f-ab09-4bce-8b17-42e3176361f7%40googlegroups.com.

[lizmil...@gmail.com]

Dear all,

I am also having some strange issues potentially associated with the update. I fit a DEC model a month or so ago without enforcing constraints on dispersal through time, and it worked just fine. I then made a dispersal multipliers matrix for the same data, but the analysis was giving me strange messages:

Stopping on error: NaNs produced in likelihood calculation. This may mean your transition matrix disallows necessary transitions.  E.g., if your ranges are 'A' and 'B', and your model is DEC, then allowing range 'AB' as a possible state is required, so that you can get from 'A' to 'B' via 'AB' as the intermediate. Alternatively, NaNs can be produced sometimes if your Maximum Likelihood (ML) search proposes weird parameter values (such as a negative rate or weight) or a parameter so small that required transitions have a probability that machine precision rounds to zero or negative.  Sometimes this seems to occur because optim, optimx, etc. propose parameters slightly outside the user-specified upper and lower (min/max) boundaries for some reason. One solution is often to narrow the min/max limits. Another solution: To have this error report an extremely low log-likelihood,, set BioGeoBEARS_run_object$on_NaN_error to something like -1e50.

This is odd because there are no zero's in my dispersal matrix. Dispersal is allowed among all areas at all times, with the smallest probability in the matrix set to 0.10. I followed recommendations in the last sentence, and this still caused a "FATAL ERROR" associated with NAs in the transition matrix. 

Then, I went to re-run the unstratified analysis from a month ago without changing the script, and I got the same error even though it was an unstratified analysis. 

Happy to email my data and scripts to Nick to help figure out the issue!

[Nick Matzke]

Hi -- thanks for the comments.  Yes, please email the files so I can double-check, but this issue is most likely just GenSA exploring the boundaries of the parameter space.  What should happen, if 

BioGeoBEARS_run_object$on_NaN_error = -1e50

...is that the inference keeps running, despite the big scary message, and just reports lnL=-1e50 and continues on searching for better lnLs, like usual.

I changed the settings a few days back to make this the new default, so try reinstalling from GitHub and see if the issue goes away.

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 https://groups.google.com/group/biogeobears.

To view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/f966c8f4-732d-49d2-81e4-a5d3e906adc7%40googlegroups.com.