Optimal hardware for large INLA analysis

Colin Beale

unread,

Jun 23, 2017, 5:22:26 AM6/23/17

to R-inla discussion group

Hi everyone,

I've a spatial besag model I'm running on a largish dataset (120k rows). On my desktop I can run the model with a poisson family in about 24hrs, not a problem. I'm just trying exactly the same models but with a zeroinflatedpoisson0 family, and it has so far run for 2 weeks with no sign of completion... I have access to a range of high performance research computing platforms, but I'm not really sure what the optimal set up would be, because I'#m not quite sure why it is so much slower. On my desktop the inla process is using 10.5GB of memory. That's not all that I have available (16GB), but it might be close to some working limit. I have access to significantly more on the HPC platform. Does anyone have any insight if allocating more memory might reduce the processing time? If it is unlikely, my job on the HPC would be killed after 2 weeks and I'm already running well on that level of processing. The alternative option would be to run on a GPU processor, but might involve a slightly trickier setup. So I'm wondering if anyone has any useful insights? Even why the zeroinflatedpoisson0 family takes so much longer to fit seems worthwhile understanding!

Thanks,

Colin

Finn Lindgren

unread,

Jun 23, 2017, 5:58:41 AM6/23/17

to Colin Beale, R-inla discussion group

Did you run with verbose=TRUE so you could see if it's was each step in the optimization that was slow and/or it used many steps?

(Run inside a "screen" terminal to not have to have a session open all the time)

Finn

--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.
To post to this group, send email to r-inla-disc...@googlegroups.com.
Visit this group at https://groups.google.com/group/r-inla-discussion-group.
For more options, visit https://groups.google.com/d/optout.

Haakon Bakka

unread,

Jun 23, 2017, 7:09:27 AM6/23/17

to Finn Lindgren, Colin Beale, R-inla discussion group

For why zeroinflated takes longer: it might be because you have an additional hyper-parameter, the zero-inflation probability. To check this, fix that parameter to some value and compare that run time to the poisson run time.

In general: You want to use good starting values for the optimizer, for example from the poisson result or running on a reduced dataset.

For your specific likelihood, zeroinflatedpoisson0, I think you can remove all the zeros from your dataset, and then just do a separate "ad-hoc" estimate of the zero-probability.

Kind regards,

Haakon Bakka

On 23 June 2017 at 11:58, Finn Lindgren <finn.l...@gmail.com> wrote:

Did you run with verbose=TRUE so you could see if it's was each step in the optimization that was slow and/or it used many steps?
(Run inside a "screen" terminal to not have to have a session open all the time)

Finn

On 23 Jun 2017, at 10:22, Colin Beale <colin...@york.ac.uk> wrote:

Hi everyone,

I've a spatial besag model I'm running on a largish dataset (120k rows). On my desktop I can run the model with a poisson family in about 24hrs, not a problem. I'm just trying exactly the same models but with a zeroinflatedpoisson0 family, and it has so far run for 2 weeks with no sign of completion... I have access to a range of high performance research computing platforms, but I'm not really sure what the optimal set up would be, because I'#m not quite sure why it is so much slower. On my desktop the inla process is using 10.5GB of memory. That's not all that I have available (16GB), but it might be close to some working limit. I have access to significantly more on the HPC platform. Does anyone have any insight if allocating more memory might reduce the processing time? If it is unlikely, my job on the HPC would be killed after 2 weeks and I'm already running well on that level of processing. The alternative option would be to run on a GPU processor, but might involve a slightly trickier setup. So I'm wondering if anyone has any useful insights? Even why the zeroinflatedpoisson0 family takes so much longer to fit seems worthwhile understanding!

Thanks,
Colin

--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion-group+unsub...@googlegroups.com.
To post to this group, send email to r-inla-discussion-group@googlegroups.com.

Visit this group at https://groups.google.com/group/r-inla-discussion-group.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion-group+unsub...@googlegroups.com.
To post to this group, send email to r-inla-discussion-group@googlegroups.com.

Colin Beale

unread,

Jun 23, 2017, 8:50:00 AM6/23/17

to R-inla discussion group, colin...@york.ac.uk

Thanks for this suggestion. I've run it for a couple of hours like with verbose, and I'm seeing the sort of output below. It looks like each iteration isn't too slow, but (a) there are lots and (b) it is tripping over sometimes, which probably further slows it down. It may well be as Haakon comments that providing intelligent starting values would solve it, but I'm not entirely certain how to do that... My model looks like this:

interp.modSnr.final <- inla(snare ~ offset(log(trans.length)) + tc.s + tc.s2 +

villages.s + sampleyear + ranger.zone + rivers.s + rangers.s +

f(ID, model="besag", graph="adj.txt",

hyper = list(prec = list(prior = "loggamma",

param = c(0.1, 1), initial = 0.01))),

data=all.data, family = "zeroinflatedpoisson0",

control.predictor = list(compute = TRUE, link = "log"),

control.compute = list(dic = TRUE, cpo = TRUE), verbose = TRUE)

max.logdens= -184568.024812 fn= 5 theta= -0.000012 0.005021 range=[-0.107 4.367]