knitr Rnw file (with cache=TRUE option)

156 views
Skip to first unread message

Olga Lyashevska

unread,
Mar 8, 2013, 8:11:43 AM3/8/13
to r-inla-disc...@googlegroups.com
Dear all,

I have cache=TRUE option enabled in Rnw file using knitr package, which
should ensure that when evaluating code chunks, the cached chunks are
skipped, but the objects created in these chunks are (lazy-) loaded from
previously saved databases (.rdb and .rdx) files.

This is especially handy because each inla call takes up to one hour to
run, so you do not really want to run it each time. However, what I see
is that first time I compile document, it works well, but subsequently
the object created with 'inla' (i.e. results) becomes empty.

Can anybody confirm this issue? What is your approach?
Maybe I can still fiddle with options a bit, right now I am only using
cache=T, and no dependencies across chunks.

Thanks
Olga


INLA help

unread,
Mar 8, 2013, 8:48:04 AM3/8/13
to Olga Lyashevska, r-inla-disc...@googlegroups.com
I havn't seen this. can you make a stripped-down example showing this
behaviour? does the same happens with cacheSweave?

H


--
Håvard Rue
he...@r-inla.org

Olga Lyashevska

unread,
Mar 8, 2013, 8:51:35 AM3/8/13
to he...@r-inla.org, r-inla-disc...@googlegroups.com
On 03/08/2013 02:48 PM, INLA help wrote:
> does the same happens with cacheSweave?
I cant tell this as I am not using cacheSweave.

Regards,
Olga

Finn Lindgren

unread,
Mar 8, 2013, 8:58:22 AM3/8/13
to Olga Lyashevska, r-inla-disc...@googlegroups.com
Not sure if the following explains the specific problem you have, but it
might:

If you by any chance are using spde models, I could see this happening
since the spde objects have to be recreated for each new R session in
order to ensure the existence of the appropriate data files on disk.
Thus, it might fail or succeed depending on precisely what is done in
the code and by sweave.

Whether that is the issue here or not, I'll move that issue higher on
the "TODO" list to fix. (It's a long-known issue that hasn't really
seemed to be a major issue until now; the fix should just involve moving
an already marked block of code from one function to an appropriate
place in the code for the f()-function, but noone has gotten around to
doing that yet...)

Finn

Olga Lyashevska

unread,
Mar 10, 2013, 6:59:44 PM3/10/13
to Finn Lindgren, r-inla-disc...@googlegroups.com
On 03/08/2013 02:58 PM, Finn Lindgren wrote:
> If you by any chance are using spde models, I could see this happening
> since the spde objects have to be recreated for each new R session in
> order to ensure the existence of the appropriate data files on disk.
> Thus, it might fail or succeed depending on precisely what is done in
> the code and by sweave.

Ok, I did a little test here. I removed all cashed files and recompiled
everything using "knitr". First time I compiled my document everything
looked as expected.

However, second time I noticed problems in objects created by the
following code:

mesh1 <- inla.mesh.create(d0Prooi@coords,plot.delay=1)
mesh2 <- inla.mesh.create(d0Prooi@coords,refine=T,plot.delay=1)
par(mfrow = c(2, 1))
plot(mesh1)
## Error: error in evaluating the argument
Error: internal error -3 in R decompress1

mesh4 <- inla.mesh.create(loc=d0Prooi@coords,
boundary=grenzen4,
refine=list(max.edge=10000),
plot.delay=1)

A<-inla.spde.make.A(mesh4,loc=d0Prooi@coords) #length n
## Error:
internal error -3 in R decompress1

Do you think this might be caused by spde code?

On the positive side, other people told me to experience problems with
knitr cache, so I might just try to switch back to sweave.

Regards,
Olga


Finn Lindgren

unread,
Mar 10, 2013, 7:34:41 PM3/10/13
to Olga Lyashevska, r-inla-disc...@googlegroups.com
On 10 mar 2013, at 22:59, Olga Lyashevska <o.lyash...@gmail.com> wrote:
> plot(mesh1)
> ## Error: error in evaluating the argument
> Error: internal error -3 in R decompress1

Thanks for testing!
The errors you get does indicate a problem with cashing of the mesh objects. Those do not have the known issue I mentioned about the SPDE objects, and should be cacheable.

> On the positive side, other people told me to experience problems with
> knitr cache, so I might just try to switch back to sweave.

This does point towards a problem with the cashing mechanism, yes, since each mesh object is simply a structured collection of information stored as a list of list, with vectors, "matrix" and "Matrix" objects. Please let me know if the sweave caching mechanism works better.

Finn
Reply all
Reply to author
Forward
0 new messages