Function runslow error message

[Lamarck Rocha]

Dear friends,

I would like a help, because I'm a little inexperienced in R.

I've been running the BioGeoBEARS script. Even with all packages and version of R (4.1.0) updated, according to comments here in the group. When I enter the function:

runslow = TRUE

resfn = "Psychotria_DEC_M0_unconstrained_v1.Rdata"

if (runslow)

    {

    res = bears_optim_run (BioGeoBEARS_run_object)

    res

    save (res, file = resfn)

    resDEC = res

    } else {

    # Loads to "res"

    load (resfn)

    resDEC = res

    }

I get the error message:

Error in assign ("last.warning", NULL, envir = baseenv ()):

  it is not possible to add 'last.warning' binding to the base environment

I don't really know where the error is, as all the previous functions to it don't give me error message.

Before BioGeoBEARS ran well, but when I migrated to the new R, I believe there was an error in the installation or conflict with previous versions of the packages (even uninstalled and checked to uninstall them).

From now on, I thank you immensely!

Lamarck

[Peter Löwenberg Neto]

Dear Lamarck,

I've got the same error today.

How did you manage to solve it?

Peter

[Nick Matzke]

Hi -- it's possible that they changed something in the new version of R -- however, I just downloaded & installed the new R (4.1 for Mac), reinstalled all dependencies from CRAN and then BioGeoBEARS with devtools, and the example script has run without errors. 

A google search turns up our own thread on this question, which is a bit depressing, but further investigation suggests this is about a line of code in bears_optim_run that clears old warnings, which is useful so that you see just the warnings in bears_optim_run.

"The error message is Error in assign("last.warning"...) occurres on non-vanilla R platforms (i.e. MRO and RRO), because last.warning is locked by default. To unlock the binding, use

unlockBinding("last.warning", baseenv())."

However, adding unlockBinding to BioGeoBEARS actually CREATED the error on my system where it did not exist before.  So probably some peoples' computers have this setting by default in R 4.1.

Instead, I have removed the last.warning stuff and changed to:

 "savedwarning <- warnings()" added this to the bears_optim_run() function...which works.

New code below and now on GitHub.

Cheers, Nick

PS for the other error message, see further below.

===========

 # Wipe out any old/previous warnings()

########################################################
# NOTE 2021-06-20_NJM:
# As of R4.1, it appears this causes an error on
# some R systems
#
# Error in assign ("last.warning", NULL, envir = baseenv ()):
  # it is not possible to add 'last.warning' binding to the base environment
  #
  # This page:
  # https://stackoverflow.com/questions/5725106/r-how-to-clear-all-warnings
  #
  # ...suggests:
  #
  # The error message is Error in assign("last.warning"...) occurres on non-vanilla R platforms
  # (i.e. MRO and RRO), because last.warning is locked by default. To unlock the binding, use
  # unlockBinding("last.warning", baseenv()). This implementation is consistent with ?warning, w
  # which says "If warn is zero (the default), a read-only variable last.warning is created."
  #  – Jthorpe Mar 9 '16 at 21:39
  #
#######################################################
# BUT, THIS ADVICE NO LONGER WORKS IN VERSION 4.1

#unlockBinding("last.warning", baseenv())
# Adding the above CAUSES the error:
# Error in assign("last.warning", NULL, envir = baseenv()) :
  # cannot add binding of 'last.warning' to the base environment
 
# assign("last.warning", NULL, envir = baseenv())

# Replacing with:
savedwarning <- warnings()
# ...which works

===========

This other error is probably unrelated:

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

"Error in calc_loglike_sp(tip_condlikes_of_data_on_each_state = tip_condlikes_of_data_on_each_state, :

Stopping on error in dense exponentiation downpass (right branch): NaNs produced in likelihood calculation. This may mean your transition matrix disallows necessary transitions. Eg, 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 optimx, optimx, etc. propose parameters slightly outside the user- specified upper and lower (min/max) boundaries for some reason.

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

The most common cause of this is having a complex time-stratification / manual dispersal multipliers / areas-allowed setup, which overly constrains the analysis such that your range data are impossible under the model. This can result in e.g. all-0s in the calculation of likelihoods by state, resulting in a 0/0 error which produces NaN and then the error message.  So, remove all constraints and add them back in one at a time to see which one causes problems, then modify accordingly, there are a lot of old help on this on the Google Group IIRC>

Cheers,

Nick

On Sat, Jun 19, 2021 at 12:56 PM Lamarck Rocha <lamarc...@gmail.com> wrote:

Hi Peter,

I uninstalled and re-installed the package, the message disappeared and the function is executed, but it gives me an error message. Several lines appear with NaN and a message:

"Error in calc_loglike_sp(tip_condlikes_of_data_on_each_state = tip_condlikes_of_data_on_each_state, :

Stopping on error in dense exponentiation downpass (right branch): NaNs produced in likelihood calculation. This may mean your transition matrix disallows necessary transitions. Eg, 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 optimx, optimx, etc. propose parameters slightly outside the user- specified upper and lower (min/max) boundaries for some reason.

Another solution: To have this error report an extremely low log-likelihood, set BioGeoBEARS_run_object$on_NaN_error to something"

Even with incessant new attempts I couldn't go on without coming across this message. I ended up without my analysis.

If anyone can help me, I greatly appreciate it!

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/biogeobears/2abda349-29ac-44ee-b95a-18f27b015ed3n%40googlegroups.com.