Transfer Alert

This paper was transferred from another journal. As a result, its full editorial history (including decision letters, peer reviews and author responses) may not be present.

PONE-D-20-35172

Evaluation of serverless computing for scalable execution of a joint variant calling workflow

PLOS ONE

Dear Dr. John,

Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process.

Please submit your revised manuscript by Feb 05 2021 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file.

Please include the following items when submitting your revised manuscript:

• A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.
• A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.
• An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: http://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols

We look forward to receiving your revised manuscript.

Kind regards,

Jacopo Soldani

Academic Editor

PLOS ONE

Journal requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

2. Thank you for stating the following financial disclosure:

"The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript"

At this time, please address the following queries:

1. Please clarify the sources of funding (financial or material support) for your study. List the grants or organizations that supported your study, including funding received from your institution.
2. State what role the funders took in the study. If the funders had no role in your study, please state: “The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.”
3. If any authors received a salary from any of your funders, please state which authors and which funders.
4. If you did not receive any funding for this study, please state: “The authors received no specific funding for this work.”

Please include your amended statements within your cover letter; we will change the online submission form on your behalf.

3. Thank you for stating the following in the Competing Interests section:

"KA and AJ are developers of SWEEP , the workflow tool used in the publication"

Please confirm that this does not alter your adherence to all PLOS ONE policies on sharing data and materials, by including the following statement: "This does not alter our adherence to  PLOS ONE policies on sharing data and materials.” (as detailed online in our guide for authors http://journals.plos.org/plosone/s/competing-interests).  If there are restrictions on sharing of data and/or materials, please state these. Please note that we cannot proceed with consideration of your article until this information has been declared.

Please include your updated Competing Interests statement in your cover letter; we will change the online submission form on your behalf.

Please know it is PLOS ONE policy for corresponding authors to declare, on behalf of all authors, all potential competing interests for the purposes of transparency. PLOS defines a competing interest as anything that interferes with, or could reasonably be perceived as interfering with, the full and objective presentation, peer review, editorial decision-making, or publication of research or non-research articles submitted to one of the journals. Competing interests can be financial or non-financial, professional, or personal. Competing interests can arise in relationship to an organization or another person. Please follow this link to our website for more details on competing interests: http://journals.plos.org/plosone/s/competing-interests

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Partly

Reviewer #2: Yes

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: I Don't Know

Reviewer #2: N/A

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: ## Information on the Contribution

Manuscript ID: PONE-D-20-35172

Title: "Evaluation of serverless computing for scalable execution of a joint variant calling workflow"

Author(s): Aji John, Kathleen Muenzen, Kristiina Ausmees

Summary:

In the presented work, authors describe the modeling and execution of GATK best-practice joint variant calling pipeline using SWEEP, a process engine offered as a service, which supports executing tasks hosted on AWS and Azure. In particular, SWEEP focuses on the serverless-style execution, meaning that it supports invoking business logic hosted using FaaS/CaaS offerings from AWS and Azure. The workflows are defined using a custom DSL which also provides control flow constructs for implementing composite integration patterns such as scatter-gather. The main contribution of this paper is the description of the modeled workflow and results/pitfalls of its execution using SWEEP in combination with AWS/Azure. In general, the paper reads well and provides some interesting insights related to the topic of serverless workflows. However, the publication has inaccuracies related to the description of research design and the novelty of presented insights, which affects the overall quality of the work.

========================

## Comments

========================

1. Authors need to highlight the difference from the previously published work (John et al. "SWEEP: Accelerating Scientific Research Through Scalable Serverless Workflows")

The original work that introduces SWEEP also presents a case study (Section 4.1) which focuses on modeling the variant calling workflow. From the workflow modeling perspective, the workflow presented in this paper is not significantly different from the already published case study. It would be helpful if authors emphasize how the workflow presented in this paper is different. Additionally, since no source code was referenced in the previously-published work, for readers not from the bioinformatics field it might look like a small delta from the previously-published work.

2. Authors need to provide more technical details about the workflow execution

* Both in the paper and in the GitHub repository authors state that the modeled workflow was executed on AWS and Azure. However, in the Discussion section (page 12, line 222) authors mention that due to technical limitations it was not possible to execute some tasks hosted on AWS. It is not quite clear, which tasks were executed on which provider and how this influenced the modeled workflow(s). It would be helpful if authors emphasize which actions are required from users to model-deploy-execute a SWEEP-based workflow, and how AWS/Azure come into play here. In case some tasks from the modeled workflow were executed ONLY on Azure, this means that the actual workflow is not a single-cloud workflow and, among other issues, requires considering costs of inter-cloud data transfers too.

* The implementation requirements related to function/container code are not clear. Since AWS and Azure impose different requirements on source code, integration with service offerings, and packaging formats, is it the case that SWEEP workflows can only be enacted on multiple providers if the code does not use provider-specific features at all? In addition, the invocation of FaaS functions can happen differently on AWS and Azure, e.g., HTTP-based using API Gateways, events, direct calls from the source code. The question is which requirements SWEEP workflows impose on the function code. In case API Gateways are used to invoke functions, the costs of API Gateway offerings have to be included into the picture as well, similar to data transfer costs if cross-cloud interactions were needed for enacting the workflow.

* It is stated that SWEEP workflows require actual functions/containers to be already deployed on the target provider, although its API has endpoints for uploading functions. As stated before, it would be helpful if authors clarify the actions required from users to model/deploy (both workflow and functions/containers), and execute a SWEEP workflow.

3. Authors need to explain why using SWEEP is more beneficial than using provider-specific orchestrators such as AWS Step Functions(SF) and Azure Durable Functions(DF)

Both SF and DF are mature orchestrators supporting using FaaS/CaaS offerings from AWS and Azure which provide out-of-the-box service integration, error handling, etc.

From the description of the process it is not clear, why SWEEP is more beneficial to use.

Firstly, constructs allowing implementing composite integration patterns such as scatter-gather are present in SF and DF, together with means to automate the deployment of code/workflows, whereas this work has to be done manually in SWEEP. Moreover, since it is not quite clear which communication type is used to trigger functions/containers, the costs of using SWEEP might incur not only the per-request costs, but also additional service offerings such as AWS API Gateway, making the overall costs more expensive than using SF, for example. In the best case, authors might provide a comparison between SWEEP and solutions from AWS/Azure to highlight pluses/minuses of using SWEEP workflows, e.g., cross-cloud workflow orchestration becomes possible, bioinformatics pipelines execution is more straightforward, etc.

4. Phrasing:

-- page 3, line 35: "As SWEEP is fully built on the serverless framework, ..."

This is confusing, Serverless framework is a deployment automation tool, whereas SWEEP is presented as a serverless orchestrator / workflow management system.

-- page 4, line 64: "... using the Function-as-a-Service (FaaS) paradigm."

-- page 4, line 66: "... using Container-as-a-Service (CaaS) services."

"cloud service model" instead of paradigm/services?

Reviewer #2: The authors contribute a work in the area of workflows based on cloud functions. This is an industrially relevant area as evidenced by serverless workflows offered commercially by cloud providers.

The domain for applying the workflows is genomics, in particular genome sequencing with joint-variant workflows. It is not the first article discussing the combination of serverless computing and bioinformatics. In 2019, Niu et al. studied high-performance sequence comparison, and Crespo-Cepeda et al. investigated the potential of the combination in general. Unfortunately, neither of these works are referenced so it remains unclear how much overlap and novelty there is.

SWEEP uses functions and containers to execute workflow tasks. It is not clear if CaaS refers to traditional long-running container services (e.g. pure Docker or Kubernetes), or to short-lived executions (e.g. Fargate, Google Cloud Run, Knative), and whether the statelessness is hence an issue for both. Fargate and ACI are mentioned later on, yet it is not clear why all tasks per runtime get the same memory allocation, and why the memory allocated to functions is much smaller (e.g. 3 GB instances would be possible with Lambda and would speed up execution). That should all be clarified in the section on definition of workflows. More technical details on the "as opposed to Docker Hub base images" would also be useful - whether it merely concerns the installation of additional packages, or also the interface to the containers and how information is passed to them and results are retrieved. It looks like in total (Fig. 1) 5 out of 18 workflow steps are cloud functions, whereas much the paper makes it sound as if most of the workflow was. What were the decisions to go for either technology in each step? This knowledge would greatly contribute to the value of the manuscript as it would help readers facing similar challenges.

Fig. 2 positions a cost of zero to a runtime of around 3 hours. First, the graph starts at around 15000s, or around 4 hours; and furthermore, it would imply 0 or negative cost for shorter runtimes whereas the pricing model of FaaS/CaaS is linear except for free tiers. It is not clear if the graph was created and interpreted correctly. Fig. 2 is also not referenced from the text. Some attention should be given to it because it represents the value proposition of the paper, that using SWEEP would be cost-effective.

The manuscript as a whole could be made more readable. The acronym GVCF is not explained; presumably the G stands for Gathering but the rest is unclear. What does it do and why did you choose it as representative workflow that would allow to generalise findings? A typical JSON excerpt of GVCF in your own SWEEP language would further help in understanding the nature of the workflow and how it would map to cloud functions or containers. Moreover, most providers - including AWS - offer their own languages for serverless workflows; a short statement of differentiation would also be helpful (that might focus on portability and ability to also include containerised endpoints).

Nitpicks: Fig. 1 has dashed edges but the caption talks of dotted edges.

Datasets and sample workflows are made available and look reasonable.

For transparency reasons, it would be helpful to point out in the review materials that SWEEP is linked to a startup. KM is listed on the SWEEP website as lead software engineer but the competing interests only mention KA and AJ.

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

PONE-D-20-35172R1

Evaluation of serverless computing for scalable execution of a joint variant calling workflow

PLOS ONE

Dear Dr. John,

Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process.

Please submit your revised manuscript by May 21 2021 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file.

Please include the following items when submitting your revised manuscript:

• A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.
• A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.
• An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: http://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols.

We look forward to receiving your revised manuscript.

Kind regards,

Jacopo Soldani

Academic Editor

PLOS ONE

Journal Requirements:

Please review your reference list to ensure that it is complete and correct. If you have cited papers that have been retracted, please include the rationale for doing so in the manuscript text, or remove these references and replace them with relevant current references. Any changes to the reference list should be mentioned in the rebuttal letter that accompanies your revised manuscript. If you need to cite a retracted article, indicate the article’s retracted status in the References list and also include a citation and full reference for the retraction notice.

Additional Editor Comments (if provided):

Please address the minor comments provided by the reviewers in preparing the final version of your manuscript.

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #1: (No Response)

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: N/A

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: Manuscript ID: PONE-D-20-35172_R1

Title: "Evaluation of serverless computing for scalable execution of a joint variant calling workflow"

Author(s): Aji John, Kathleen Muenzen, Kristiina Ausmees

In this work, the authors presented the modeling and execution of GATK best-practice joint variant calling pipeline using SWEEP, a process engine offered as a service, which supports executing tasks hosted on AWS and Azure.

The revision addresses issues raised by reviewers related to the original submission.

The difference between the previous work and the workflow presented in this work is explained.

Authors also provide clarifications on how cloud provider services were used, highlighting that this workflow can only be executed in a multi-cloud setting due to limitations of certain cloud services.

Authors provide a high-level clarification on interaction with provider-hosted function/containers, which is probably motivated by SWEEP commercialization plans. While the aspects of interaction with provider-specific services are not directly required in the context of this work, such technicalities influence the code implementation requirements. In particular, to achieve the vendor-agnosticism mentioned as one of the main motivations for using SWEEP, functions/containerized applications might have to be developed without relying on provider-specific libraries. For example, if an Azure-specific Java annotations are used in a function, deploying it to AWS Lambda would require additional efforts (or does the system handle such cases for users?). The documentation also does not specify how functions/containerized applications need to be implemented, e.g., implementing certain interfaces, adhering to certain data formats. In my opinion, highlighting such requirements would strengthen the work.

Overall, I am glad to accept this work when more details on code implementation requirements are provided.

Reviewer #2: This is a revised manuscript that addresses most of the previously raised concerns. Indeed, the motivation for using SWEEP given the characteristics of the bioinformatics/genomics workflow needs is now more clear, and the authors contribute a critical view on using serverless platforms for the workflow steps not requiring these execution features. The nature of the work has not changed, it remains an experience report discussing and experimentally measuring the SWEEP migration of a given pipeline. Such experiences help the serverless systems community to achieve more applicable system designs. I have no major points to complain, but if another round of minor edits is possible, there are some more rough edges that could improve with more attention.

A critical point is the limitation on number of tasks. If each task stays within the specified disk limit and yet the task fails (and requires retries), that might be labelled more explicitly a bug in ACI, or it is some other effect that should be explained in greater detail. Given the potential blocker impact on running other large workflows, it would also be interesting to know if for instance Fargate suffers from the same effect. The preference for ACI over Fargate is explained with the greater disk size (50 vs 10 GB), but that greater disk may not be worth much when the instances fail randomly.

Adaptive selection of storage is mentioned as possible extension of the work. It would be great if some hints were given how this could be done in a way that the workflow will benefit, for instance by accomodating some latency issues by juggling between instance disk, externally mounted disk (on AWS Lambda) and managed storage (AWS S3/ABS) equivalent.

A useful addition, if space permits, would be an elaboration on the modifications of container images compared to those found on Docker Hub. Specifically, if this merely concerns the ability to invoke them in as ACI, or any other changes beyond the invocation interface.

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

Evaluation of serverless computing for scalable execution of a joint variant calling workflow

PONE-D-20-35172R2

Dear Dr. John,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Jacopo Soldani

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #1: All comments have been addressed

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: N/A

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: (No Response)

Reviewer #2: This work demonstrates experimentally and analytically how to run a genome sequencing workflow with a new workflow engine called SWEEP. The contribution is mostly in the analytical nature, because the workflow engine itself is not new. The article can be read easily, the covered technologies are relevant subjects for investigation, and the use case of genome sequencing is of societal importance.

According to the response letter and highlighted changes, the authors have addressed a few issues that were left from previous iterations. It looks like the modifications are almost too brief or superficial (on pages 10 and 11), but given that no major changes were requested from them, the present manuscript is fine for me to be published.

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No