English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

The SPAdes assembler for metagenome assembly is a long-running applicationcommonly used at the NERSC supercomputing site. However, NERSC, like many othersites, has a 48-hour limit on resource allocations. The solution is to chaintogether multiple resource allocations in a single run, usingcheckpoint-restart. This case study provides insights into the "pain points" inapplying a well-known checkpointing package (DMTCP: Distributed MultiThreadedCheckPointing) to long-running production workloads of SPAdes. This work hasexposed several bugs and limitations of DMTCP, which were fixed to support thelarge memory and fragmented intermediate files of SPAdes. But perhaps moreinteresting for other applications, this work reveals a tension between thetransparency goals of DMTCP and performance concerns due to an I/O bottleneckduring the checkpointing process when supporting large memory and many files.Suggestions are made for overcoming this I/O bottleneck, which providesimportant "lessons learned" for similar applications.

Checkpointing SPAdes for Metagenome Assembly: Transparency versus Performance in Production