Many thanks - attached is an example that is replicable on my system, Ubuntu 13.10, both in RStudio and R vanilla. This is NOT replicatable on a Mac, nor on a Linux cluster running Centros 5.5 It includes the C code that I am trying to run in deSolve, along with an R script to run the example. It seems to be connected to re-loading the DLL for the C function that I am running within ode. If I unload and reload the file, as I've done here, deSolve ceases to work for all functions (as you say, ODEPACK is locked, but never unlocked). However, even just calling "dyn.load(bmod.so)" a second time without unloading it will cause the problem. This isn't terribly urgent, since I've found a workaround (included in the example) - But -- if there is a more elegant solution, I would love to try it. Thanks agian, Adam
On Wed, Nov 6, 2013 at 3:56 PM, Thomas Petzoldt <thpe at simecol.de> wrote:
On 11/6/2013 6:50 PM, Adam Clark wrote:> Addendum: unloading and reloading deSolve.so does indeed fix the problem:
library.dynam.unload("deSolve", libpath=paste(.libPaths()[1],
"//deSolve", sep=""))
library.dynam("deSolve", package="deSolve", lib.loc=.libPaths()[1])
However, this is a little clunky, and seems like overkill. Does
anybody have an idea for a more elegant workaround?
Adam,
the solver lock is used for the ODEPACK solvers to prevent simultaneous
(i.e. nested) calls of the solver within R session, because the ODEPACK
algorithms use some global variables. The RK solvers do not use
global variables, so they have no lock.
If you use the ode solvers in the intended way, an internal call of:
on.exit(.C("unlock_solver"))
should always unlock the solver, even if the function is exited due to
an error. However, your example may point to another problem in the
code, for which we need a minimal reproducible example.
As a first workaround, you may try to call:
.C("unlock_solver")
... but calling an internal .C package function outside a package is
generally not recommended, so you should definitely try to find the real
cause of your problem.
Thomas
PS: please move this thread to either R-Devel or (preferred) to the
specialised mailing list:
mailto:R-sig-dynamic-models at r-project.org
Adam Clark University of Minnesota, EEB 100 Ecology Building 1987 Upper Buford Circle St. Paul, MN 55108 (857)-544-6782