first commit

README.md

@@ -0,0 +1,112 @@
+> Author： Huang Yechao
+> 
+> E-mail：1721070009@fudan.edu.cn
+> 
+> Git: http://choppy.3steps.cn/huangyechao/target-germline.git
+> 
+> Last Updates: 16/1/2019
+
+## 安装指南
+```
+# 激活choppy环境
+source activate choppy-latest
+# 安装app
+choppy install LiXiangNan/hrd_score
+```
+
+## App概述
+描述App解决了什么问题，适用范围与局限性。
+
+示例：
+![](http://kancloud.nordata.cn/2019-01-24-Screen%20Shot%202019-01-24%20at%2014.57.49.png)
+![](http://kancloud.nordata.cn/2019-01-24-Screen%20Shot%202019-01-24%20at%2014.58.56.png)
+
+
+## 流程与参数
+此模块详细描述App包含的流程与参数，请参考[流程描述参考示例](https://software.broadinstitute.org/gatk/best-practices/workflow?id=11145)
+
+参数指封装的软件所用到的参数，参数罗列可参考：
+![](http://kancloud.nordata.cn/2019-01-24-Screen%20Shot%202019-01-24%20at%2015.05.21.png)
+
+## 软件解决问题的思路
+自研软件需要增加此模块内容，用于描述解决问题的思路。
+
+## App输入变量与输入文件
+自定义文件格式的务必给出文件格式的详细说明，如下链接所示：[文件格式描述参考示例](http://cole-trapnell-lab.github.io/cufflinks/file_formats/index.html)
+
+输入变量是指定义在App中允许用户修改的值，可通过以下命令输出：
+
+```
+choppy samples <app_name>
+```
+
+此外，choppy支持定义默认值，App用户可通过以下命令修改defaults文件中定义的值。
+
+```
+choppy config --app-name <app_name> --key <key> --value <value>
+```
+
+App开发者定义在App中的变量，可同时在App的defaults文件中预设默认值。defaults文件是一个json文件，如下所示：
+
+```
+{
+    "var_1": "value_1"
+}
+```
+
+## App输出文件
+输出文件务必给出文件格式的详细说明以及示例，如下链接所示：[文件格式描述参考示例](http://cole-trapnell-lab.github.io/cufflinks/file_formats/index.html)
+
+## 结果展示与解读
+GSEA结果解读示例：
+
+> ### 1. Enrichment score（ES）
+>
+> ES是GSEA最初的结果，反应全部杂交data排序后，在此序列top或bottom富集的程度。
+> ES原理：扫描排序序列，当出现一个功能集中的gene时，增加ES值，反之减少ES值，所以ES是个动态值。最终ES的确定是讲杂交数据排序序列所在位置定义为0，ES值定义为距离排序序列的最大偏差.
+> - ES为正，表示某一功能gene集富集在排序序列前方
+> - ES为负，表示某一功能gene集富集在排序序列后方。
+> 图中的最高点为此通路的ES值，中间表示杂交数据的排序序列。竖线表示此通路中出现的芯片数据集中的gene。
+>
+> ### 2. NES
+> 
+> 由于ES是根据分析的数据集中的gene是否在一个功能gene set中出现来计算的，但各个功能gene set中包含的gene数目不同，且不同功能gene set与data之间的相关性也不同，因此，比较data set在不同功能gene set中的富集程度要对ES进行标准化处理，也就是NES
+> NES=某一功能gene set的ES/数据集所有随机组合得到的ES平均值
+> NES是主要的统计量。
+> 
+> ### 3. FDR
+> 
+> NES确定后，判断其中可能包含的错误阳性发现率。FDR=25%意味着对此NES的确定，4次可能错  1次。GSEA结果中，高亮显示FDR<25%的富集set。因为从这些功能gene中最可能产生有意义的假设，促进进一步研究。大多数情况下，选FDR<25%是合适的，但是，假如分析的芯片data set较少，选择的是探针随机组合而不是表型组合，若p不严格，那么应该选FDR<5%。一般而言，NES绝对值越大，FDR值就越小，说明富集程度高，结果可靠。
+> 
+> ### 4. 名义p值 nominal p-value
+> 
+> 描述的是针对某一功能gene子集得到的富集得分的统计显著性，显然，p越小，富集性越好。
+> 
+> **以上4个参数中，只有FDR进行了功能gene子集大小和多重假设检验矫正，而p值没有，因此，如果结果中有一个高度富集的功能gene子集，而其有很小的名义p-value和大的FDR意味着富集并不显著。**
+> 
+> 我的一个具体结果解读：
+> 
+> > 92/681 gene sets are  upregulated in PH
+> > 0 gene sets are significantly enriched at FDR<25%
+> > 1 gene sets are significantly enriched at n p-value <1%
+> > 1 gene sets are significantly enriched at n p-value <5%
+> 
+> 在选择的BP中，有681个gene sets，92个PH中上调，其中75%的正确率支持0条子集上调，1个BP的gene表达上调名义p值<0.01。总体结果并不理想。
+> 
+> ### 5. 备注
+> 
+> #### GSEA富集结果太少说明：
+> 
+> 无gene set被富集。可能是因为分析的样本太少，关注的生物信息太微弱，或正在分析的功能集不能很好代表你所关心的生物过程，但仍然可以看下top ranked gene sets，这些信息可能会为你的假说提供微弱的证据。当然也可以尝试考虑分析其他gene sets，或增加samples
+> 
+> #### GSEA富集结果太多说明：
+> 
+> 太多的功能子集被富集了。可能是因为很多的gene sets代表同一生物信号，这可以在gene sets中查看leading edge sbusets来查看。或者也可以查看具体区别进行加工，比如samples来自不同labs，操作者不一样等。
+
+## CHANGELOG
+CHANGELOG参考示例：
+![](http://kancloud.nordata.cn/2019-01-24-Screen%20Shot%202019-01-24%20at%2015.08.35.png)
+
+## FAQ
+FAQ参考示例：
+![](http://kancloud.nordata.cn/2019-01-24-Screen%20Shot%202019-01-24%20at%2015.06.39.png)

defaults

@@ -0,0 +1,3 @@
+{
+
+}

docker/README.md

@@ -0,0 +1,10 @@
+## Docker 镜像说明
+此 Choppy App 共包含 2 个 Docker 镜像，分别为 my_program_1 和 my_program_2 的运行环境。相关的代码及其Dockerfile详解见各程序目录下的README.md.
+
+若采用`choppy build`命令构建 docker 镜像，则 Dockerfile 会自动生成。使用方式：
+1. 切换目录至docker
+2. 进入代码所在目录，以 my_program_1 为例
+   ```
+   cd my_program_1
+   choppy build my_program_1 0.1.0 --parser r --main-program maftools_general.R --dep bioconductor-maftools:1.6.15
+   ```

inputs

@@ -0,0 +1,6 @@
+{
+  "{{ project_name }}.input_file": "{{ intput_file }}",
+  "{{ project_name }}.genelist": "{{ genelist }}",
+  "{{ project_name }}.cluster_config": "{{ cluster if cluster != '' else 'OnDemand ecs.sn1ne.xlarge img-ubuntu-vpc' }}",
+  "{{ project_name }}.docker": "registry.cn-shanghai.aliyuncs.com/pgx-docker-registry/maftools-0.1.0"
+}

report/about/choppy.md

@@ -0,0 +1,321 @@
+---
+id: quick-intro
+title: 快速指南：Choppy for Reproducible Omics Pipeline
+sidebar_label: 快速指南
+---
+{% raw %}
+> Author: Yechao Huang
+>
+> Email: 17210700095@fudan.edu.cn
+>
+> Date: 2019-01-18
+
+# Choppy快速指南
+
+## Pipeline 分析三步走
+
+基于`Choppy平台`进行 Pipeline 分析十分简单高效，只需要三步即可轻松搞定(**点击进入[演示视频](http://kancloud.nordata.cn/2019-01-20-choppy.mp4)**)：
+
+1. 登陆**[Choppy App Store](http://choppy.3steps.cn)**，挑选符合自己需求的 App，并安装
+2. 准备 App 所需的 Samples 文件
+3. 提交任务
+
+## 使用 APP 提交任务
+
+> 基于 choppy 封装的 app 可以使得用户可以通过自定义或者下载的 `app` 简单快速的进行可重复并且可溯源的任务提交
+
+- 选择所要使用的 **app** 并生成相应的 **samples.csv** 文件（以 dna-germline-0.1.0 为例）
+
+  ```bash
+  choppy samples dna-germline-0.1.0 --output dna-germline.csv
+  ```
+
+  通过上述命令会生成一个对应于使用的 app 的一个 .csv 格式文件，按照表头的内容将所涉及到的变量（如：fastq 文件在 OSS 上的路径、对应的 sample 的名字、sample_id 等）填入到文件中（注意以 “,” 进行分隔），在填写的过程中可以直接在 linux 系统下进行操作也可以下载到本地 PC 上使用 excel 进行操作。
+
+  > sample_id : 对于每一个提交的样本名会根据 sample_id 来创建一个目录，里面包含了当前样本所运行时使用的 wdl 文件以及 input 文件，以便于对样本任务的溯源工夫
+
+- 根据生成的 samples.csv 文件批量提交任务
+
+  ```bash
+  choppy batch dna-germline-0.1.0 samples.csv --project-name project
+  ```
+
+  当出现如下所示的信息时，表明当前任务提交成功：
+
+  ```bash
+  Sample ID: 1, Workflow ID: a6a24b7d-bea3-48fe-93f6-7b7aa8ce9b5f
+  Successed: 1, /home/huangyechao/project/submitted.csv
+  ```
+
+  其中，第一行为所提交的样本的名字以及每一个样本对应的 workflow ID ，可用于查询该任务的运行状态；当有多个样本时，会有多行出现。
+  第二行为统计 app 端成功的样本数，并且会生成包含有当次任务成功提交时的所有信息
+  第三行为为统计 app 端失败的样本数（若没有失败则不会产生）
+
+- 根据生成的 Workflow ID 可以进行任务状态的查询，使用命令如下
+
+  ```bash
+  choppy query -s a6a24b7d-bea3-48fe-93f6-7b7aa8ce9b5f
+  ```
+
+  此时会显示出该样本任务的状态信息，当显示为 submitted 时，表示任务正在向云端及进行投递过程中； 显示为 Running 时，表示任务已经成功在云端运行；当显示为 Failed 时，表示任务运行失败。
+  使用 **-m** 参数可以查看更多关于任务的日志信息：
+
+  ```bash
+  choppy query -s -m a6a24b7d-bea3-48fe-93f6-7b7aa8ce9b5f
+  ```
+
+- 当任务提交成功之后，可登陆到阿里云控制台中，在批量计算的作业列表中查询任务的运行情况；通常当任务提交到阿里云计算平台时，会需要几分钟的服务器配置时间之后任务才会开始进行计算。
+
+## 构建属于自己 WDL
+
+在构建 **WDL** 之前，需要先对 **WDL** 的基本结果有一定的了解，其基本结构包含以下部分：`workflow`，`task`，`call`, `command`以及`output`（详见[WDL Base Structure](https://software.broadinstitute.org/wdl/documentation/structure)）
+
+以下是对构建 **WDL** 脚本的一个简单教程（以 [Sentieon](http://goldenhelix.com/products/sentieon/index.html) 的 DNA-seq 为例）：
+
+## 单个 task 的构建
+
+- **command**： 通常我们在构建**pipeline** 时，是将每一步分析写入到一个脚本中，并调用脚本的方式串行使用，如下所示：
+
+  ```bash
+  $SENTIEON_INSTALL_DIR/bin/bwa mem -M -R "@RG\tID:$group\tSM:$sample\tPL:$pl" -t $nt $fasta $fastq_1 $fastq_2 | $SENTIEON_INSTALL_DIR/bin/sentieon util sort -o ${sam}.sorted.bam -t $nt --sam2bam -i -
+  ```
+
+  以上为 **DNA-seq** 中比对的命令，在 **WDL** 中这部分将会书写在 `command` 部分，如下所示：
+
+  ```
+  command <<<
+  		set -o pipefail
+  		set -e
+  		export SENTIEON_LICENSE=此处替换为你的license
+  		nt=$(nproc)
+  		${SENTIEON_INSTALL_DIR}/bin/bwa mem -M -R "@RG\tID:${group}\tSM:${sample}\tPL:${pl}" -t $nt ${ref_dir}/${fasta} ${fastq_1} ${fastq_2} | ${SENTIEON_INSTALL_DIR}/bin/sentieon util sort -o ${sample}.sorted.bam -t $nt --sam2bam -i -
+  >>>
+  ```
+
+  可以看到在 **WDL** 中，就是将日常所使用的命令填入在 `command` 中，并用`{ }`或者`<<< >>>`进行引用（后者主要是在于有多个命令运行时使用）。
+
+  > 注意: `${变量}`的形式是 **WDL** 所识别的变量，当命令中的变量是`$变量`的形式时，**WDL**是无法识别的，如例子中的 `$nt` 在之前已经对其进行了定义；
+
+- **output**： `command` 部分完成之后，需要对于该命令的输出进行定义，比对的结果产生的文件为`${sample}.sorted.bam` 以及 `${sample}.sorted.bam.bai` ，因此需要在 `output` 中对结果的输出进行定义：
+
+  ```bash
+  output {
+  		File sorted_bam = "${sample}.sorted.bam"
+  		File sorted_bam_index = "${sample}.sorted.bam.bai"
+  	}
+  ```
+
+  左边为当前 `task` 输出结果的命名，右边为所输出结果文件名，用 `" "` 进行引用；
+
+  当有多个结果文件输出时，只有在 `output` 中进行了定义的结果文件才会输出，没有定义的将不会输出到结果目录中；
+
+- **runtime**： 对于每一个 `task` 的运行环境需要进行定义，包括所使用的软件的 `docker`信息，所使用的服务器配置信息，以及服务器的系统盘以及数据盘大小：
+
+  ```bash
+  runtime {
+  		dockerTag:docker
+      	cluster: cluster_config
+      	systemDisk: "cloud_ssd 40"
+      	dataDisk: "cloud_ssd " + disk_size + " /cromwell_root/"
+  	}
+  ```
+
+  `dockerTag` 为所使用的 `docker` 信息，此处以变量表示
+
+  `cluster` 为运行命令是所选用的服务器实例信息（[参照阿里云服务器 ECS](https://help.aliyun.com/document_detail/25378.html?spm=a2c4g.11186623.6.545.8e452f98mSzIST)）
+
+  `systemDisk` 为使用的系统盘的大小，默认为 cloud_ssd 40G
+
+  `dataDisk` 为使用的数据盘的大小信息，默认类型为 `cloud_ssd` ，挂载点为 `/cromwell_root/`
+
+  > 注意：在系统盘和数据盘的写法上，需注意不同的变量之间存在空格
+
+- 在将 `command` 主体部分改写完成之后，需要在 `task` 中声明 `command` 中所使用的变量形式：
+
+  ```bash
+  task mapping {
+  	File fastq_1
+  	File fastq_2
+  	File ref_dir
+  	String fasta
+  	String SENTIEON_INSTALL_DIR
+  	String group
+  	String sample
+  	String pl
+  	String docker
+  	String cluster_config
+  	String disk_size
+
+  	command <<<
+  		....
+  	>>>
+  	runtime {
+  		...
+  	}
+
+  	output {
+  		...
+  	}
+  }
+
+  ```
+
+  对于在 `task` 中所使用到的变量，都需要在 `task` 上面先进行声明，通常有两种形式 `File` 以及 `String`
+
+## workflow 的构建
+
+> `workflow` 应用于在所有的 `task` 构建完成之后，对于每个步骤进行调用以及每个步骤之间的依赖关系的一个说明，包括以下两个部分 `import`，`call`
+
+```bash
+import "./tasks/mapping.wdl" as mapping
+import "./tasks/Metrics.wdl" as Metrics
+
+workflow sentieon  {
+	call mapping.mapping as mapping {
+		input:
+		SENTIEON_INSTALL_DIR=SENTIEON_INSTALL_DIR,
+		group=sample,
+		sample=sample,
+		pl="ILLUMINAL",
+		....
+	}
+	call Metrics.Metrics as Metrics {
+		input:
+		....
+	}
+}
+```
+
+- **import** ：表明构建的 `workflow` 中所需要使用的步骤信息，这部分内容可根据使用者分析过程中需要的内容进行自定义：
+
+  ```bash
+  import "./tasks/mapping.wdl" as mapping
+  import "./tasks/Metrics.wdl" as Metrics
+  import "./tasks/Dedup.wdl" as Dedup
+  import "./tasks/deduped_Metrics.wdl" as deduped_Metrics
+  import "./tasks/Realigner.wdl" as Realigner
+  import "./tasks/BQSR.wdl" as BQSR
+  import "./tasks/Haplotyper.wdl" as Haplotyper
+  ```
+
+  引号内的内容为所要调用的 `task` 信息， `as` 之后的内容（如 `mapping` `Dedup` 等为所定义的步骤的别名）在命名时，应尽量使得命名简单并能包含所需的信息
+
+- **call** : 是对所引用的 `task` 中的变量进行传递以及对不同的步骤之间的依赖关系进行说明：
+
+  ```bash
+  call mapping.mapping as mapping {
+  		input:
+  		SENTIEON_INSTALL_DIR=SENTIEON_INSTALL_DIR,
+  		group=sample,
+  		sample=sample,
+  		pl="ILLUMINAL",
+  		fasta=fasta,
+  		ref_dir=ref_dir,
+  		fastq_1=fastq_1,
+  		fastq_2=fastq_2,
+  		docker=docker,
+  		disk_size=disk_size,
+  		cluster_config=cluster_config
+  	}
+
+  	call Metrics.Metrics as Metrics {
+  		input:
+  		SENTIEON_INSTALL_DIR=SENTIEON_INSTALL_DIR,
+  		fasta=fasta,
+  		ref_dir=ref_dir,
+  		sorted_bam=mapping.sorted_bam,
+  		sorted_bam_index=mapping.sorted_bam_index,
+  		sample=sample,
+  		docker=docker,
+  		disk_size=disk_size,
+  		cluster_config=cluster_config
+  	}
+  ```
+
+  首先需要对 `call` 进行声明，`mapping.mapping as mapping` 中，第一个 `mapping` 是与 `import` 中的别名保持一致，第二个 `mapping` 是与 `task` 中使用的命名保持一致（`task mapping {...}`），第三个 `mapping` 是作为在 `workflow` 中的命名； `input` 是将 `task` 中所使用的变量进行定义，`=`左边是变量名，右边是对变量的赋值，当所使用的变量会重复使用时，可以将其继续以变量的形式进行声明，并在`call`的外部进行声明;
+
+  在构建 `pipeline` 中，通常某步的输入文件是上一步的结果输出，在 `call` 中，可以通过对上一步结果文件的引用使得 `workflow` 能自动判别程序的依赖关系，并采取串行或者并行计算；如上所示，`Metrics` 的输入文件是上一步 `mapping` 的输出结果文件，因此在 `input` 中 `mapping.sorted_bam` 表明该步骤使用到 `mapping` 中的 `sorted_bam` 文件，因此只有当 `mapping` 这一步运行结束时，`Metrics` 才会启动运行。
+
+- **变量声明**：在`workflow` 中，同样需要对 `call` 中没有赋值的变量进行声明：
+
+  ```bash
+  	File fastq_1
+  	File fastq_2
+
+  	String SENTIEON_INSTALL_DIR
+  	String sample
+  	String docker
+
+  	File ref_dir
+  	File dbmills_dir
+  	File dbsnp_dir
+  	String db_mills
+  	String fasta
+  	String dbsnp
+  	String disk_size
+  	String cluster_config
+  ```
+
+  类似于 `task` 中的变量声明方式，需要 `File` 及 `String` 声明变量类型， 对于 `workflow` 中的变量，都会在 `input` 中进行赋值；
+
+- **input**： 在 WDL 中所使用的变量，都会在 `input` 文件中进行赋值。变量的读取规则为，在 `call` 的内部使用的变量如果在 `workflow` 中的变量声明中同样进行了定义，则变量的传递顺序为 `input` --> `workflow` 变量声明 --> `call` ，当没有在 `workflow` 中声明，则变量的传递顺序为 `input` --> `call`
+
+  ```bash
+  {
+    "sentieon.fasta": "GRCh38.d1.vd1.fa",
+    "sentieon.ref_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    "sentieon.dbsnp": "dbsnp_146.hg38.vcf",
+    "sentieon.fastq_1": "oss://pgx-storage-backend/WGS_germline/WGC107658D_combined_R1.fastq.gz",
+    "sentieon.SENTIEON_INSTALL_DIR": "/opt/sentieon-genomics",
+    "sentieon.dbmills_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    "sentieon.db_mills": "Mills_and_1000G_gold_standard.indels.hg38.vcf",
+    "sentieon.cluster_config": "OnDemand ecs.sn2ne.2xlarge img-ubuntu-vpc",
+    "sentieon.docker": "localhost:5000/sentieon-genomics:v2018.08.01 oss://pgx-docker-images/dockers",
+    "sentieon.dbsnp_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    "sentieon.sample": "WGC107658D",
+    "sentieon.disk_size": "500",
+    "sentieon.fastq_2": "oss://pgx-storage-backend/WGS_germline/WGC107658D_combined_R2.fastq.gz"
+  }
+  ```
+
+  `input` 文件的生成可以使用 `womtool`(参见[womtool](https://github.com/broadinstitute/cromwell/releases/tag/36)使用), 同时也可使用 `womtool` 对所写的 **WDL** 进行验证。
+
+  ```bash
+  java -jar womtool.jar validate 2.wdl   ####WDL验证
+  java -jar womtool.jar inputs 3step.wdl  ### 生成input文件生成
+  ```
+
+- **将 WDL 脚本封装成为 APP**：单个 **WDL** 文件撰写完成之后，可以通过简单的改写就可将 **WDL** 文件封装成为``choppy`中的 **APP** 使用，用于批量提交，改写规则如下：
+
+  - 将`workflow` 中的 `workflow_name`变为变量引用形式：
+
+    ```bash
+    workflow {{ project_name }} {
+       ...
+    }
+    ```
+
+    在 `choppy` 中对于变量是通过 `{{ }}`的形式进行引用，此处 `project_name` 是在使用 **APP** 提交任务时定义的变量，可用于提交任务之后所生成的可追溯的文件；
+
+  - 将 `input` 中的相应的 `project_name` （即上面所示例子中的 `sentieon` ）改为 `{{project_name}}` ；此外对于后面所需要改变的参数变量，可以使用 `{{ }}` 进行变量引用：
+
+    ```bash
+    {
+    	"{{ project_name }}.fasta": "GRCh38.d1.vd1.fa",
+    	"{{ project_name }}.ref_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    	"{{ project_name }}.dbsnp": "dbsnp_146.hg38.vcf",
+    	"{{ project_name }}.fastq_1": "{{ read1 }}",
+    	"{{ project_name }}.SENTIEON_INSTALL_DIR": "/opt/sentieon-genomics",
+    	"{{ project_name }}.dbmills_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    	"{{ project_name }}.db_mills": "Mills_and_1000G_gold_standard.indels.hg38.vcf",
+    	"{{ project_name }}.cluster_config": "{{ cluster if cluster != '' else 'OnDemand ecs.sn1ne.4xlarge img-ubuntu-vpc' }}",
+    	"{{ project_name }}.docker": "localhost:5000/sentieon-genomics:v2018.08.01 oss://pgx-docker-images/dockers",
+    	"{{ project_name }}.dbsnp_dir": "oss://pgx-reference-data/GRCh38.d1.vd1/",
+    	"{{ project_name }}.sample": "{{ sample_name }}",
+    	"{{ project_name }}.disk_size": "{{ disk_size }}",
+    	"{{ project_name }}.regions": "{{ regions }}",
+    	"{{ project_name }}.fastq_2": "{{ read2 }}"
+    }
+    ```
+{{% endraw %}}
+    至此整个 APP 封装完毕，可以在 `choppy` 中使用

report/about/license.md

@@ -0,0 +1,29 @@
+# License
+
+The legal stuff.
+
+---
+
+## BSD License for the Report
+
+Copyright © 2014, Tom Christie. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification,
+are permitted provided that the following conditions are met:
+
+Redistributions of source code must retain the above copyright notice, this list
+of conditions and the following disclaimer. Redistributions in binary form must
+reproduce the above copyright notice, this list of conditions and the following
+disclaimer in the documentation and/or other materials provided with the
+distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

report/defaults

@@ -0,0 +1,3 @@
+{
+    "cached_file_list": []
+}

tasks/general.wdl

@@ -0,0 +1,27 @@
+task general {
+	
+    File input_file
+    File output_dir
+	
+    command <<<
+        set -o pipefail
+	set -e
+        maftools -p general_non_parameter ${output_dir} ${input_file}
+    >>>
+
+    runtime {
+	docker:docker
+    	cluster: cluster_config
+    	systemDisk: "cloud_ssd 40"
+    }
+
+    output {
+	File file_summary = "${output_dir}/MAF_summary.png"
+	File file_oncoplot = "${output_dir}/Oncoplot.png"
+	File file_tt = "${output_dir}/Transition_and_transversion.png.png"
+	File file_rainfall = "${output_dir}/Rainfall.png"
+	File file_genecloud = "${output_dir}/Genecloud.png"
+	File file_interaction = "$output_dir}/Drug_gene_interaction.png"
+	File file_pathway = "${output_dir}/Oncogenic_signaling_pathways.png"
+    }
+}

tasks/specific.wdl

@@ -0,0 +1,27 @@
+task specific {
+    File input_file
+    File output_dir
+    File genelist
+	
+    command <<<
+        set -o pipefail
+	set -e
+        maftools -p specific_gene_as_input ${output_dir} ${input_file} ${genelist}
+    >>>
+
+    runtime {
+	docker:docker
+    	cluster: cluster_config
+    	systemDisk: "cloud_ssd 40"
+    }
+
+    output {
+	File file_summary = "${output_dir}/MAF_summary.png"
+	File file_oncoplot = "${output_dir}/Oncoplot.png"
+	File file_tt = "${output_dir}/Transition_and_transversion.png.png"
+	File file_rainfall = "${output_dir}/Rainfall.png"
+	File file_genecloud = "${output_dir}/Genecloud.png"
+	File file_interaction = "$output_dir}/Drug_gene_interaction.png"
+	File file_pathway = "${output_dir}/Oncogenic_signaling_pathways.png"
+    }
+}

workflow.wdl

@@ -0,0 +1,24 @@
+import "./tasks/general.wdl" as general
+import "./tasks/specific.wdl" as specific
+
+workflow {{ project_name }} {
+    File input_file
+
+    call general.general as general {
+	input:
+            output_dir='general',
+            input_file=input_file,
+	    docker=docker,
+	    cluster_config=cluster_config
+    }
+
+    {% if genelist %}
+    call specific.specific as specific {
+        input:
+       	    output_dir='specific',
+            input_file=input_file,
+            docker=docker,
+            cluster_config=cluster_config
+    } 
+    {% endif %}
+}