Mastodon

Michael Sumnerwe ran a multi-decade extraction of points-in-time for 46000 points 1993-2024 (at bottom level, it's variable so we indexed the level upfront for each point) ran this the "traditional way" using <a href="https://rstats.me/tags/terra" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#terra</a> <a href="https://rstats.me/tags/GDAL" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#GDAL</a> to extract points from relevant layers (point-sets grouped by date,level) for salt,temp,u,v,w,mld - ran on 28cpus with <a href="https://rstats.me/tags/furrr" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#furrr</a>/#future took ~80min will get a public dataset to repeat the example for illustration (elephant seals I hope)

Michael Sumner<a href="https://rstats.me/tags/rstats" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#rstats</a> future_map in <a href="https://rstats.me/tags/furrr" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#furrr</a> on <a href="https://rstats.me/tags/slurm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#slurm</a> has stopped being my friend ... multicore or multisession, both take way longer than normal - tested on small sets with 6 cores, smallish sets with 24, and the real job with 128 coresparallel::parLapply works fine in the small or all 128 coresany ideas?

Recent searches

Search options

Administered by:

Server stats:

#furrr