running 'unmarked' on a 'supercomputer'

[Mark W. Miller]

I tried analyzing a large data set involving dozens of sample periods using unmarked, but the model did not seem to run.  Eventually I got the model to run in MARK, but the run time was 3 days.  Now I think I have access to a university 'supercomputer'.  

Might there be any advantages to trying to run the model in unmarked on that supercomputer?  I have been told that unless I can take advantage of parallel processing the supercomputer might not be much faster than my desktop.  I am not sure the optimization process for a given model could be divided among multiple cores.  I have read here about parboot being divided among cores, but I think that is simply performing some simulations on one core and other independent simulations on another core, etc.  Perhaps a set of models could be analyzed quicker with multiple cores by assigning one model per core.  However, if an individual model cannot run on the desktop, as seemingly in my case, perhaps availability of multiple cores will not help.

Perhaps the best option with a very large data set and a complex model with many sample periods would be to try Andrew Gelman's new Bayesian software Stan on a supercomputer.

Thank you for any thoughts.

Mark

[Richard Chandler]

Hi Mark,

What model are you trying to fit? I don't think multiple cores will help you here, but if you are using a function that has the "engine="C" option, then you can speed up run time by using a 64-bit machine. The only other easy option I can think of is to thin your data. 

Richard

[thomas ingersoll]

I'm going to chime in and agree with Richard here. If running a bootstrap, a cluster can help as it can be turned into a parallel process. Also for running multi-iteration simulations in R, the cluster can really speed things up. But, clusters usually have slow processors and can be weak on RAM per node. R can easily bog down due to maxing out the RAM. I've seen R do this sometimes when working with a large dataset. A 64-bit, 4 core workstation with a lot of RAM and fast-processor can be a better choice in these circumstances.

[Mark W. Miller]

Thanks for the replies.  Richard, I am using the multi-season occupancy model.  I am using a 64-bit machine and will check for the engine='C' option.  I have approximately 50 seasons and at least 4 regions.  I think the model crashed the last time I tried to run it with unmarked, but that was months ago.  Maybe it simply ran imperceptibly slow, in which case the engine='C' option may help.

Mark

[Ted Jones]

I concur with Chandler and Ingersoll. I generally use an early
generation 2.14GHz core2duo processor with 3.2GB RAM, and experimented
fitting a pcount() model on other much more powerful machines (eg, a
computer with 16GB RAM and a high end Xeon processor), and a variety
of the virtual computers built on the Amazon Cloud. Gains in speed
appeared relatively modest. I was able to shave about 10 minutes off
of the 45 minute processing time required to fit the model on my daily
computer using the fastest computers benchmarked. Granted, a time
savings of about 20% is more meaningful when processing requires days,
weeks or months... Processing on older Pentium IV machines was not
substantially slower compared to the core2duo. My tests indicated
that CPU power was more limiting than RAM (7GB vs 16GB RAM not much
different with comparable processors).

If you ultimately need to estimate dispersion from the full model or
want to examine GOF using the parboot() simulator, your 3 days of
processing required to fit your model will likely be an issue. For
example, my full pcount() model required about 10 hrs for each
parboot() iteration. Ideally I wanted to run a very large number of
bootstrap simulations, but even just 100 simulations would take
100x10hrs = 1000hrs (or 41 days). The parboot() simulations are a
'stupidly' redundant processing task, which means R can be used to
take advantage of multiple CPU cores via parallel processing.

On that note, Chandler has provided some very helpful details about
how to parse the parboot() simulations across multiple processor cores
(see http://groups.google.com/group/unmarked/browse_thread/thread/b71a7551ea6d8e03/99e70d253ed3816d?lnk=gst&q=parallel+processing).
From Chandler's guidance, I succeeded to parse 100 parboot()
simulations across 20 processor cores on a virtual machine I created
on the Amazon Cloud, and cut the estimated 41 days of processing to
just about 1.5 days.

Good luck and please let us know if you learn any new tricks!

-Ted

[Kery Marc]

Dear Mark,

 

does your data matrix contain many missing values ? If so, it may be more efficient to fit the model in BUGS or JAGS where (to me at least), it is easier to throw them out and only model the observed data.

 

I have often fitted dynamic occupancy models to large and extremely unbalanaced data sets (e.g., several 1000 sites, ~20 years and up to 100 or so 2ry occasions), where 98% of the balanced 3-dimensional data array were NAs. unmarked crashed, but fitting the model in WinBUGS in the „vertical format“ worked well. I can send code if you like.

 

Kind regards  ---  Marc