[R-sig-dyn-mod] [R] deSolve, unresolved namespace error

[Adam Clark]

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
> https://stat.ethz.ch/mailman/listinfo/r-sig-dynamic-models
>
>
>
>
>
>
>
>
>
>


-- 
Adam Clark
University of Minnesota, EEB
100 Ecology Building
1987 Upper Buford Circle
St. Paul, MN 55108
(857)-544-6782