BACKGROUND
massively parallel / next generation sequencing  has become a central tool for many projects related to the life sciences, including fields such as molecular biology, evolutionary biology, metagenomics and oncology.
these novel technologies have brought tremendous depth to our understanding of epigenetics and are becoming widely used in many experimental setups.
recent improvements in sequencing technologies have made it commonplace to obtain  <dig> to  <dig> gigabits of data from a single experiment  <cit>  while the cost per mega base has dropped by half nearly every six months since  <dig>  <cit> .
the explosion of ngs data in the life sciences has lead to surpass the petabase barrier  <cit> .
in addition to the massive amount of data generated in the genomics era, the empiric observation that ngs analysis constitutes one of the major bottlenecks in modern genomics projects has brought new challenges including the urgent need to create efficient and reproducible analysis pipelines accessible to both biologists and bioinformaticians.
biologists have embraced ngs technologies with great enthusiasm, mainly because of the opportunities and promises they provide.
however, although ngs allows rapid assessment of genome wide changes, paradoxically, the computational power and complexity required for its analysis has significantly hindered the overall turnaround time for wet-lab scientists, many of whom rely on overwhelmed bioinformatics core facilities.
a common effort has thus been established to support the post-genomic era including the development of important interfaces such as genome browsers , annotation databases  and tools to manipulate big data files .
moreover, many scientists have contributed to the development of galaxy, an open source, web-based platform that provides various tools for ngs data analysis  <cit> .
finally, the r community is providing increased support to the field of bioinformatics by developing and providing a plethora of open source packages as part of the bioconductor consortium  <cit> .
the development of publically available tools has undoubtedly facilitated the analysis of ngs data.
however, several loopholes still remain.
for example, irrespective of how user-friendly these tools might be, they are often daunting for scientists that have little to no programming experience.
this particular segment is often brought to the dilemma of choosing between investing the effort to learn the computational skills necessary to analyze their own data or waiting for it to be analyzed by computational cores.
empirically, the majority of the decisions converge to the later.
in the meantime, scientists still heavily rely on the ability to visualize their data to steer their projects.
we thus feel that the community would strongly benefit from easy-to-use tools that do not require programming skills.
the reason such applications have never been implemented likely stems from the disparity of each individual project and the need to apply specific parameters to each of them on a case-by-case scenario.
nevertheless, there is a strong demand for tools to rapidly assess whether the technical aspect of an experiment succeeded , even though the tradeoff of using default parameters might well introduces some bias and imperfections in the analysis.
another loophole in ngs analysis is seen with more advanced users.
indeed, many computational biologists, who strongly depend on automation for the majority of their work, continue to manually manipulate files .
this apparent dichotomy can be explained by the lack of tools to support vertical integration of ngs analysis  while managing their interdependencies.
for example, the vast majority of tools that support singular repetitive tasks that can be run in parallel , rarely provide an easy solution for the integration of these tasks into a complicated multi-dimensional workflow.
as such, few softwares allow users to efficiently run custom made pipelines on the same server on which the data is stored long term.
for example, galaxy, the most widely used open-source platform for data analysis has a powerful and intuitive web-based front-end interface.
nevertheless, users are required to upload files and are often limited by various regulations including maximum job submissions, wall time and storage space.
other tools such as htstation  <cit>  require scientists to continuously follow the job statuses and manually manipulate files and keys between different steps.
these iterative and error-prone processes, which, de facto, cannot be referred to as pipelines, are cumbersome and time-consuming.
to address some of the above-discussed issues, we present neat, a framework developed to help manage chipseq and rnaseq pipelines in a robust, reproducible and user-friendly manner.
neat offers several automated modules  that can be run through double-clickable icons from any desktop or laptop, an interface that not only facilitates the analysis of ngs data, but that makes it accessible to non-expert users.
furthermore, neat includes downstream applications that allow users to effortlessly explore ngs data using a graphical user interface  display.
in summary, we believe that neat will help biologists as well as established bioinformaticians create, manage and analyze complex ngs pipelines, as well as assess ngs data within 24 h of the sequencing run completion through a simple gui.
implementation
we have created an ngs framework under the unix operating system called neat that can easily be run either through the command line or through a graphical user interface .
neat is a modular, reliable and user-friendly framework that allows users to build both chipseq and rnaseq pipeline using plain words .
neat is completely automated and supports users in the analysis of ngs data by managing all jobs and their dependencies from a single, centralized file.
neat is designed to be run by scientists with no programming experience and as such, pipelines can be build and managed using double-clickable executables on a simple laptop.
on the other hand, its modular architecture allows advanced users to easily customize neat to their own needs.
in additional, neat can be implemented in the vast majority of institutions  regardless of rules and regulations as all cluster parameters including queuing priority, node allocation, number of cpus and wall time can be parameterized from a single file.
after having installed neat using the ‘install.app’ module , the analysis consists of a 4-step process, each of which has a unique gui:  create a new project;  run neat;  download data to local computer;  run additional analyses .
although all steps can be run either on a remote server or on a local computer, step  requires high computational power and we therefore suggest running it through the gui, which will launch the pipeline on the remote high capacity cluster specified by the user.
sections ,  and  can be run locally without the need for internet access, which is an advantage for users that are uncomfortable with cloud computing or when traveling.fig.
<dig> neat architecture.
ngs data can be analyzed using neat in less than a day.
users follow a logical 4-step process, including the creation of a new project, running the pipeline on a remote server or in the cloud, transferring the data to a local computer and proceeding to the analysis.
*depicts modules that are restricted to chipseq experiments.
the modules depicted reflect a non-exhaustive list.
left-hand figure represents a conceptual framework; right hand icons represent the double-clickable executables that run the different processes
the four steps of the neat framework are described below.
in addition, step-by-step tutorials can be found in the supplemental material .
the tutorials allow users to follow through an entire ngs analysis using a provided test data set.
the test datasets, which are either h3k4me <dig> chipseq data or rnaseq data from mouse embryonic stem cells, have been truncated such that the entire analysis should take less than two hours.
running the test data will also ensure neat and its dependencies  are properly installed before submitting large, memory-savvy analyses.
step 1: creating a neat project
the first step of the neat framework is to build a new project.
this can be done through the ‘new project’ application , which will prompt users to enter some details including the directory the project will be created in and the name of the project.
once executed, the user will be asked to fill in the foremost important step of neat: the targets.txt file.
the targets.txt file is the most important piece of neat and users are expected to invest the time and effort to ensure all paths and parameters exist and are correctly set.
it is worth noting that once set, most of these parameters will not change on a specific computer cluster .
we therefore suggest that more advanced users modify the original targets.txt template file , which is used as template each time a new project is created.
this will significantly ease the process of building new projects and will minimize errors due to inexistent files or wrong paths.
for down stream analysis of neat projects , several widely used database names can be found in the species_specificities.txt file for reference .
while the upper portion of the targets.txt file sets up the backbone of neat, the bottom portion contains the details of the experimental setup including the names of the compressed fastq files , the names that the users would like to give to the samples, their relationship  and antibody specificities.
for paired-end runs, it is important to note that the sample name of the reverse-reads needs to be consistent with the forward-reads sample name, followed by ‘_r2’ .
for example, if the ‘filename’ of the forward reads is ‘psa36-1_dox_k4me3’, the corresponding reverse read file should be named ‘psa36-1_dox_k4me3_r2’.
in addition, the reverse-reads file information should be set below the ‘pe corresponding samples’ mark at the bottom of the targets.txt file instead of the ‘samples info’ section .fig.
<dig> the target.txt file.
neat is centralized around a single text file  containing all required information including sample names, inputs, their relationships, virtual paths to reference genomes, parameters, alignment and peak calling algorithms.
many of the settings are either automatically filled in when a new project is created or need to be filled in only once.
the color code helps understand which parameters are specific to the cluster ; the user ; the experiment  or different parameters
finally, in addition to containing the data processed by the pipeline, most importantly, the targets.txt file contains the building blocks of the pipeline.
these blocks are specified under the ‘steps_to_execute_pipe’ and can be written in plain english words, e.g.
‘unzip’, ‘map’, ‘filter’ etc.
the different default building blocks are described below.
as neat uses exact word matching, users that do not want to run a given block are free to delete it or rename it .
unzip
the ‘unzip’ module will unzip, rename and store fatsq files in a newly created folder within the project folder.
although this strategy can seem cumbersome for space issues, it allows systematic storage of backups without manipulating the original compressed file, which helps organize and keep track of the sequencing runs.
sequencing cores use different compression formats.
for this reason, users can specify the file extension and the unzip command in the advancedsettings.txt file .
this module will unzip the compressed files found in the directory specified in the ‘remote_path_to_orifastq_gz’ parameter and which names are found in the ‘orifilename’ column of the targets.txt file, and will rename them according to the users setup in the ‘filename’.
all files will be stored in the newly created ‘fatsq’ folder .
qc
the ‘qc’ module uses the r systempiper package  systempiper: ngs workflow and report generation environment.
url https://github.com/tgirke/systempiper) to provide a variety of high quality control outputs including per cycle quality box plots, base proportion, relative k-mer diversity, length and occurrence distribution of reads, number of reads above quality cutoffs and mean quality distribution.
the ‘qc’ building block, together with the ‘granges’ modules  are the rare exception that require the installation of external r packages.
additional information on package installation can be found in the tutorials .
chiprx
chiprx  <cit>  is a cutting edge normalization method for chipseq that performs genome-wide quantitative comparisons using a defined quantity of an exogenous epigenome, e.g.
a spike-in control.
the detailed algorithm of chip-rx has been implemented as previously published  <cit> .
for the sake of consistency, the same mapping and filtering parameters will be used for both the alignment of the standard and the spike-in epigenome.
if no spike-in controls are used, all chip-rx parameters can be dashed .
map
the ‘map’ module maps reads using either bwa  <cit>  or bowtie  <cit> .
for rnaseq projects, the splice-aware, bowtie-based tophat  <cit>  algorithm is preferred.
the standard parameters for either algorithm can be modified in the advancedsettings.txt file, including maximum number of gaps, gap extension, maximum edit distance, number of threads, mismatch and gap penalty, etc.
additional mapping algorithms can easily be implemented by advanced users .
filter
the ‘filter’ module allows the user to specify filtering parameters  including how to manage duplicate reads, minimum and maximum size of fragments, etc.
this module uses the samtools  <cit>  view, sort, rmdup and index functions.
peakcalling
the ‘peakcalling’ module specifies the algorithm used to call peaks.
neat has two well-established peak calling methods built-in by default, including macs   <cit>  and spp   <cit> .
it is worth noting that given that neat is open source and very versatile, it is easy for advanced users to implement their own peak calling algorithm as an r code .
cleanfiles
given different mapping algorithms have distinct outputs, the ‘cleanfiles’ module helps reorganize and store the different .bam and .bai files before proceeding to downstream analysis.
this allows advanced users to implement their own mapping algorithms while still taking advantage of neat’s eda modules.
granges
the ‘granges’ module creates significantly smaller granges objects , which are necessary for downstream analysis including identification of differentially regulated genes  and metagenomic analyses .
this eases and increases the efficiency of file transfer, file sharing and consolidation of projects.
in addition, the ‘granges’ module creates small size wiggle files .
wiggle files can be loaded and visualized in various genome browsers including igv  <cit> .
the compression of the file is driven in part by the binning of the data across the genome.
the bin size, which is in base pair units, can be customized in the advancedsettings.txt file.
step 2: running neat
after building a pipeline using the easy one-word method in the ‘steps_to_execute_pipe’ line of the targets.txt file, non-expert users can run the workflow using the applescript double-clickable executable .
more advanced users can run it through the command line .
the executable will prompt users to identify which project they want to run before opening a terminal and asking them  to enter their ssh password.
this will allow neat to access and run the pipeline on the computationally efficient remote cluster.
once entered, neat automatically manages job submission, queuing and dependencies.
a detailed explanation on how to follow the pipeline and a step-by-step debugging support can be found in the tutorials .
moreover, users can decide to setup automatic emailing when the pipeline has completed.
as a point of reference, running an exhaustive pipeline  on data comprising 200– <dig> million reads should not take more than  <dig> to 15 h. the project architecture of a completed neat project on the remote server including the timing and location of files and folders can be found in additional file  <dig>
step 3: download a neat project from a remote server to a local computer
the core component of neat , which is the pipeline per se, is computationally demanding and is thus preferentially ran on a remote cluster.
however, upon completion of the pipeline, users may prefer to view and analyze their data locally, e.g.
on a desktop or a laptop.
as mentioned above, neat can be used to create granges and wiggle files, which main advantage are their relatively small size compared to bam files .
in addition, these files can easily and rapidly be shared by email or in batch using standard flash drives.
to download a neat project from a remote server to a local computer, users can run the ‘transfer.app’ applescript double clickable executable , which will automatically open a terminal window and start the process.
users will be prompted to locate the neat directory and the neat project.
the ‘transfer.app’ will use all the information found in the corresponding targets.txt file to download the neat project from the remote server to the local computer.
users should be attentive as they will be asked to enter the corresponding ssh password several times.
downloading an entire project should not take more than a few minutes.
step 4: exploratory data analysis using neat
empirically, data visualization is an important milestone for wet-lab scientists.
this step is often critical for deciding the direction to take for further experiments and computational biologists often underestimate its importance.
as an effort to improve the turn around time of ngs datasets, neat supports users in the creation of wig files  that can be visualized using various genome browsers including igv  <cit> .
section  <dig> of neat also contains tools for exploratory data analysis , which supports the creation of human-readable files including pdf graphs and count tables, which can be opened and analyzed in softwares such as excel.
the tools that create these files require relatively small computational power, which allows users to experiment using a variety of different parameters ranging from cutoff values to deg stringencies.
the default eda tools consist of : metagenomic analysis , count tables and peak overlap ;  smear plots, deg analysis, consolidated count tables, rpkm, venn diagrams of gene overlap and gorilla-compatible  <cit>  differentially expressed genes lists .fig.
<dig> output examples.
neat outputs many files and graphs, some of which are depicted as examples.
a quality control of fastq files.
b metagene analysis  of the test data around all tsss.
c venn diagrams of peak overlaps.
d scatterplots for sample-to-sample comparison .
e deg smear plots with deg highlighted and annotated.
above and below are two examples of deg picked up by the pipeline
it is worth noting that the metagenomic analysis in the chipseq module can be easily customizable.
this tool allows users to visualize chromatin immunoprecipitation enrichments of various samples over specific features .
for example, using the test dataset, users can explore enrichment of an epigenetic mark  around all transcriptional start sites  of the mouse genome.
however, such analyses are not constrained to any particular region, nor to regions of similar length.
by creating a simple bed file, users can assess enrichments over their preferred regions of interest.
for example, users can visualize enrichments over all transcripts and/or enhancers.
in such case, the length will be normalized throughout all regions.
any bed-formatted file can be used for the metagenomic module.
customizing neat modules
neat was developed as a user-friendly, intuitive and versatile tool.
as such, care has been taken to allow users the ability to customize the pipeline for their own needs.
this includes easy customizable mapping algorithms, mapping and filtering parameters, peak calling algorithms and metagenenomic features .
in addition, more advanced users can efficiently develop novel modules as the code architecture has been written in a robust, logical, highly redundant and well-annotated manner.
to add a new module, advanced users can simply duplicate an existing module and integrate their custom task into the script, usually consisting of a single line of code.
the neat framework fully automates recurrent tasks such as batch job submissions, job dependencies, job queuing, error management, filing, etc., which greatly facilitates the creation of custom modules.
full support and step-by-step explanations to add customized modules can be found in the tutorials .
RESULTS
as this work presents a 'pipeline', tangible results are in the form of outputs .
supporting arguments are in-line.
CONCLUSIONS
technological revolutions often drive and precede biological revolutions.
the omics field has not been immune to this general rule.
such paradigm shifts are often followed by a period of great adaptation.
for massively parallel sequencing, developing curriculums to educate scientists with the proper skill sets will require some time.
meanwhile, the life science community is in desperate need for tools to support scientists that have been trained prior to the sequencing of the human genome.
although neat is not intended to replace thorough bioinformatics analysis per se, we believe that it provides helpful tools to accompany scientists in the analysis of ngs data and allow them to rapidly apply standard exploratory data analysis methods to assess the quality of their experiments within 24 h of the sequencing run completion.
specifically, we strongly believe that providing wet-lab scientists with simple tools to facilitate rapid data visualization, which is a significant bottleneck for many users, will greatly benefit the community and will allow one to better plan and foresee biological experiments without the need to wait for thorough bioinformatics analysis.
neat was developed for a wide audience including scientists with no a priori programming knowledge.
to this end, although neat should be self explanatory , it comes with step-by-step tutorials as well as two test datasets that will enable novice users to follow through and reproduce entire chipseq and rnaseq workflows.
in addition, given the wide diversity of interests in the life sciences, neat has been developed to be versatile, easily customizable and applicable to a wide variety of different genomes.
finally, the modular structure of neat allows advanced users and computational core facilities to easily add and modify tasks, customize settings and comply with internal rules and regulations with minimal footprint to their existing server architecture.
taken together, we believe neat will be of general interest and has the potential to be widely adopted for its versatility and ease of use.
neat is an open-source software under an mit license.
neat, including tutorials and test data, is publicly available on github .
availability and requirements
project home page: https://github.com/pschorderet/neat
operating system: mac osx
programming language: perl, r, applescript
license: neat is an open-source software under an mit license
additional files
additional file 1:
quick guide chipseq.
step-by-step guide for the analysis of chipseq datasets, including the provided test dataset.
additional file 2:
quick guide rnaseq.
step-by-step guide for the analysis of rnaseq datasets, including the provided test dataset.
additional file 3:
code architecture.
architecture of the provided neat chipseq project after completion of all steps on the remote server.
the color code highlights which files are created during which step as well as where they are stored.
additional file 4:
qc report.
qc report generated by neat when running the chip- and rnaseq test data set.
additional file 5:
quick guide to add custom modules.
step-by-step guide for the addition of custom modules.
additional file 6:
code architecture schematic.
example of a module’s architecture in neat.
the left part schematically represents the different steps that constitute each module.
the right part represents some example code and how it is imbricated.
the example reflects neat run on a torque manager system  though neat can be run on other systems as well including lsf clsuters .
additional file 7:
code architecture.
code architecture for the additional of custom modules.
custom code should replace the red font .
the module backbone as well as the submission procedures are robust, highly repetitive and will automatically manage job submission and queuing.
competing interests
the author declares no competing interests.
ps is supported by an advanced swiss national foundation fellowship  and is supported in part through the national institute of general medical sciences  grant r <dig> gm48405- <dig> awarded to robert e kingston.
i would like to acknowledge the kingston lab members for stimulating discussions, feedback and testing; particularly alan rodrigues, sharon marr, aaron plys, ozlem yildirim, ruslan sadreyev and bob kingston for critical reading during the preparation of the manuscript.

 massively parallel / next generation sequencing has become a central tool for many projects related to the life sciences, including fields such as molecular biology, evolutionary biology, metagenomics and oncology. these novel technologies have brought tremendous depth to our understanding of epigenetics and are becoming widely used in many experimental setups. recent improvements in sequencing technologies have made it commonplace to obtain to gigabits of data from a single experiment while the cost per mega base has dropped by half nearly every six months since. the explosion of ngs data in the life sciences has lead to surpass the petabase barrier. in addition to the massive amount of data generated in the genomics era, the empiric observation that ngs analysis constitutes one of the major bottlenecks in modern genomics projects has brought new challenges including the urgent need to create efficient and reproducible analysis pipelines accessible to both biologists and bioinformaticians. biologists have embraced ngs technologies with great enthusiasm, mainly because of the opportunities and promises they provide. however, although ngs allows rapid assessment of genome wide changes, paradoxically, the computational power and complexity required for its analysis has significantly hindered the overall turnaround time for wet-lab scientists, many of whom rely on overwhelmed bioinformatics core facilities. a common effort has thus been established to support the post-genomic era including the development of important interfaces such as genome browsers, annotation databases and tools to manipulate big data files. moreover, many scientists have contributed to the development of galaxy, an open source, web-based platform that provides various tools for ngs data analysis. finally, the r community is providing increased support to the field of bioinformatics by developing and providing a plethora of open source packages as part of the bioconductor consortium. the development of publically available tools has undoubtedly facilitated the analysis of ngs data. however, several loopholes still remain. for example, irrespective of how user-friendly these tools might be, they are often daunting for scientists that have little to no programming experience. this particular segment is often brought to the dilemma of choosing between investing the effort to learn the computational skills necessary to analyze their own data or waiting for it to be analyzed by computational cores. empirically, the majority of the decisions converge to the later. in the meantime, scientists still heavily rely on the ability to visualize their data to steer their projects. we thus feel that the community would strongly benefit from easy-to-use tools that do not require programming skills. the reason such applications have never been implemented likely stems from the disparity of each individual project and the need to apply specific parameters to each of them on a case-by-case scenario. nevertheless, there is a strong demand for tools to rapidly assess whether the technical aspect of an experiment succeeded, even though the tradeoff of using default parameters might well introduces some bias and imperfections in the analysis. another loophole in ngs analysis is seen with more advanced users. indeed, many computational biologists, who strongly depend on automation for the majority of their work, continue to manually manipulate files. this apparent dichotomy can be explained by the lack of tools to support vertical integration of ngs analysis  while managing their interdependencies. for example, the vast majority of tools that support singular repetitive tasks that can be run in parallel, rarely provide an easy solution for the integration of these tasks into a complicated multi-dimensional workflow. as such, few softwares allow users to efficiently run custom made pipelines on the same server on which the data is stored long term. for example, galaxy, the most widely used open-source platform for data analysis has a powerful and intuitive web-based front-end interface. nevertheless, users are required to upload files and are often limited by various regulations including maximum job submissions, wall time and storage space. other tools such as htstation require scientists to continuously follow the job statuses and manually manipulate files and keys between different steps. these iterative and error-prone processes, which, de facto, cannot be referred to as pipelines, are cumbersome and time-consuming. to address some of the above-discussed issues, we present neat, a framework developed to help manage chipseq and rnaseq pipelines in a robust, reproducible and user-friendly manner. neat offers several automated modules that can be run through double-clickable icons from any desktop or laptop, an interface that not only facilitates the analysis of ngs data, but that makes it accessible to non-expert users. furthermore, neat includes downstream applications that allow users to effortlessly explore ngs data using a graphical user interface display. in summary, we believe that neat will help biologists as well as established bioinformaticians create, manage and analyze complex ngs pipelines, as well as assess ngs data within 24 h of the sequencing run completion through a simple gui. implementation we have created an ngs framework under the unix operating system called neat that can easily be run either through the command line or through a graphical user interface. neat is a modular, reliable and user-friendly framework that allows users to build both chipseq and rnaseq pipeline using plain words. neat is completely automated and supports users in the analysis of ngs data by managing all jobs and their dependencies from a single, centralized file. neat is designed to be run by scientists with no programming experience and as such, pipelines can be build and managed using double-clickable executables on a simple laptop. on the other hand, its modular architecture allows advanced users to easily customize neat to their own needs. in additional, neat can be implemented in the vast majority of institutions regardless of rules and regulations as all cluster parameters including queuing priority, node allocation, number of cpus and wall time can be parameterized from a single file. after having installed neat using the ‘install.app’ module, the analysis consists of a 4-step process, each of which has a unique gui: create a new project; run neat; download data to local computer; run additional analyses. although all steps can be run either on a remote server or on a local computer, step requires high computational power and we therefore suggest running it through the gui, which will launch the pipeline on the remote high capacity cluster specified by the user. sections, and can be run locally without the need for internet access, which is an advantage for users that are uncomfortable with cloud computing or when traveling.fig. neat architecture. ngs data can be analyzed using neat in less than a day. users follow a logical 4-step process, including the creation of a new project, running the pipeline on a remote server or in the cloud, transferring the data to a local computer and proceeding to the analysis. *depicts modules that are restricted to chipseq experiments. the modules depicted reflect a non-exhaustive list. left-hand figure represents a conceptual framework; right hand icons represent the double-clickable executables that run the different processes the four steps of the neat framework are described below. in addition, step-by-step tutorials can be found in the supplemental material. the tutorials allow users to follow through an entire ngs analysis using a provided test data set. the test datasets, which are either h3k4me chipseq data or rnaseq data from mouse embryonic stem cells, have been truncated such that the entire analysis should take less than two hours. running the test data will also ensure neat and its dependencies  are properly installed before submitting large, memory-savvy analyses. step 1: creating a neat project the first step of the neat framework is to build a new project. this can be done through the ‘new project’ application, which will prompt users to enter some details including the directory the project will be created in and the name of the project. once executed, the user will be asked to fill in the foremost important step of neat: the targets.txt file. the targets.txt file is the most important piece of neat and users are expected to invest the time and effort to ensure all paths and parameters exist and are correctly set. it is worth noting that once set, most of these parameters will not change on a specific computer cluster. we therefore suggest that more advanced users modify the original targets.txt template file, which is used as template each time a new project is created. this will significantly ease the process of building new projects and will minimize errors due to inexistent files or wrong paths. for down stream analysis of neat projects, several widely used database names can be found in the species_specificities.txt file for reference. while the upper portion of the targets.txt file sets up the backbone of neat, the bottom portion contains the details of the experimental setup including the names of the compressed fastq files, the names that the users would like to give to the samples, their relationship and antibody specificities. for paired-end runs, it is important to note that the sample name of the reverse-reads needs to be consistent with the forward-reads sample name, followed by ‘_r2’. for example, if the ‘filename’ of the forward reads is ‘psa36-1_dox_k4me3’, the corresponding reverse read file should be named ‘psa36-1_dox_k4me3_r2’. in addition, the reverse-reads file information should be set below the ‘pe corresponding samples’ mark at the bottom of the targets.txt file instead of the ‘samples info’ section.fig. the target.txt file. neat is centralized around a single text file containing all required information including sample names, inputs, their relationships, virtual paths to reference genomes, parameters, alignment and peak calling algorithms. many of the settings are either automatically filled in when a new project is created or need to be filled in only once. the color code helps understand which parameters are specific to the cluster; the user; the experiment or different parameters finally, in addition to containing the data processed by the pipeline, most importantly, the targets.txt file contains the building blocks of the pipeline. these blocks are specified under the ‘steps_to_execute_pipe’ and can be written in plain english words, e.g. ‘unzip’, ‘map’, ‘filter’ etc. the different default building blocks are described below. as neat uses exact word matching, users that do not want to run a given block are free to delete it or rename it. unzip the ‘unzip’ module will unzip, rename and store fatsq files in a newly created folder within the project folder. although this strategy can seem cumbersome for space issues, it allows systematic storage of backups without manipulating the original compressed file, which helps organize and keep track of the sequencing runs. sequencing cores use different compression formats. for this reason, users can specify the file extension and the unzip command in the advancedsettings.txt file. this module will unzip the compressed files found in the directory specified in the ‘remote_path_to_orifastq_gz’ parameter and which names are found in the ‘orifilename’ column of the targets.txt file, and will rename them according to the users setup in the ‘filename’. all files will be stored in the newly created ‘fatsq’ folder. qc the ‘qc’ module uses the r systempiper package systempiper: ngs workflow and report generation environment. url https://github.com/tgirke/systempiper) to provide a variety of high quality control outputs including per cycle quality box plots, base proportion, relative k-mer diversity, length and occurrence distribution of reads, number of reads above quality cutoffs and mean quality distribution. the ‘qc’ building block, together with the ‘granges’ modules are the rare exception that require the installation of external r packages. additional information on package installation can be found in the tutorials. chiprx chiprx is a cutting edge normalization method for chipseq that performs genome-wide quantitative comparisons using a defined quantity of an exogenous epigenome, e.g. a spike-in control. the detailed algorithm of chip-rx has been implemented as previously published. for the sake of consistency, the same mapping and filtering parameters will be used for both the alignment of the standard and the spike-in epigenome. if no spike-in controls are used, all chip-rx parameters can be dashed. map the ‘map’ module maps reads using either bwa or bowtie. for rnaseq projects, the splice-aware, bowtie-based tophat algorithm is preferred. the standard parameters for either algorithm can be modified in the advancedsettings.txt file, including maximum number of gaps, gap extension, maximum edit distance, number of threads, mismatch and gap penalty, etc. additional mapping algorithms can easily be implemented by advanced users. filter the ‘filter’ module allows the user to specify filtering parameters including how to manage duplicate reads, minimum and maximum size of fragments, etc. this module uses the samtools view, sort, rmdup and index functions. peakcalling the ‘peakcalling’ module specifies the algorithm used to call peaks. neat has two well-established peak calling methods built-in by default, including macs and spp. it is worth noting that given that neat is open source and very versatile, it is easy for advanced users to implement their own peak calling algorithm as an r code. cleanfiles given different mapping algorithms have distinct outputs, the ‘cleanfiles’ module helps reorganize and store the different.bam and.bai files before proceeding to downstream analysis. this allows advanced users to implement their own mapping algorithms while still taking advantage of neat’s eda modules. granges the ‘granges’ module creates significantly smaller granges objects, which are necessary for downstream analysis including identification of differentially regulated genes and metagenomic analyses. this eases and increases the efficiency of file transfer, file sharing and consolidation of projects. in addition, the ‘granges’ module creates small size wiggle files. wiggle files can be loaded and visualized in various genome browsers including igv. the compression of the file is driven in part by the binning of the data across the genome. the bin size, which is in base pair units, can be customized in the advancedsettings.txt file. step 2: running neat after building a pipeline using the easy one-word method in the ‘steps_to_execute_pipe’ line of the targets.txt file, non-expert users can run the workflow using the applescript double-clickable executable. more advanced users can run it through the command line. the executable will prompt users to identify which project they want to run before opening a terminal and asking them to enter their ssh password. this will allow neat to access and run the pipeline on the computationally efficient remote cluster. once entered, neat automatically manages job submission, queuing and dependencies. a detailed explanation on how to follow the pipeline and a step-by-step debugging support can be found in the tutorials. moreover, users can decide to setup automatic emailing when the pipeline has completed. as a point of reference, running an exhaustive pipeline on data comprising 200– million reads should not take more than to 15 h. the project architecture of a completed neat project on the remote server including the timing and location of files and folders can be found in additional file step 3: download a neat project from a remote server to a local computer the core component of neat, which is the pipeline per se, is computationally demanding and is thus preferentially ran on a remote cluster. however, upon completion of the pipeline, users may prefer to view and analyze their data locally, e.g. on a desktop or a laptop. as mentioned above, neat can be used to create granges and wiggle files, which main advantage are their relatively small size compared to bam files. in addition, these files can easily and rapidly be shared by email or in batch using standard flash drives. to download a neat project from a remote server to a local computer, users can run the ‘transfer.app’ applescript double clickable executable, which will automatically open a terminal window and start the process. users will be prompted to locate the neat directory and the neat project. the ‘transfer.app’ will use all the information found in the corresponding targets.txt file to download the neat project from the remote server to the local computer. users should be attentive as they will be asked to enter the corresponding ssh password several times. downloading an entire project should not take more than a few minutes. step 4: exploratory data analysis using neat empirically, data visualization is an important milestone for wet-lab scientists. this step is often critical for deciding the direction to take for further experiments and computational biologists often underestimate its importance. as an effort to improve the turn around time of ngs datasets, neat supports users in the creation of wig files that can be visualized using various genome browsers including igv. section of neat also contains tools for exploratory data analysis, which supports the creation of human-readable files including pdf graphs and count tables, which can be opened and analyzed in softwares such as excel. the tools that create these files require relatively small computational power, which allows users to experiment using a variety of different parameters ranging from cutoff values to deg stringencies. the default eda tools consist of: metagenomic analysis, count tables and peak overlap; smear plots, deg analysis, consolidated count tables, rpkm, venn diagrams of gene overlap and gorilla-compatible differentially expressed genes lists.fig. output examples. neat outputs many files and graphs, some of which are depicted as examples. a quality control of fastq files. b metagene analysis of the test data around all tsss. c venn diagrams of peak overlaps. d scatterplots for sample-to-sample comparison. e deg smear plots with deg highlighted and annotated. above and below are two examples of deg picked up by the pipeline it is worth noting that the metagenomic analysis in the chipseq module can be easily customizable. this tool allows users to visualize chromatin immunoprecipitation enrichments of various samples over specific features. for example, using the test dataset, users can explore enrichment of an epigenetic mark around all transcriptional start sites of the mouse genome. however, such analyses are not constrained to any particular region, nor to regions of similar length. by creating a simple bed file, users can assess enrichments over their preferred regions of interest. for example, users can visualize enrichments over all transcripts and/or enhancers. in such case, the length will be normalized throughout all regions. any bed-formatted file can be used for the metagenomic module. customizing neat modules neat was developed as a user-friendly, intuitive and versatile tool. as such, care has been taken to allow users the ability to customize the pipeline for their own needs. this includes easy customizable mapping algorithms, mapping and filtering parameters, peak calling algorithms and metagenenomic features. in addition, more advanced users can efficiently develop novel modules as the code architecture has been written in a robust, logical, highly redundant and well-annotated manner. to add a new module, advanced users can simply duplicate an existing module and integrate their custom task into the script, usually consisting of a single line of code. the neat framework fully automates recurrent tasks such as batch job submissions, job dependencies, job queuing, error management, filing, etc., which greatly facilitates the creation of custom modules. full support and step-by-step explanations to add customized modules can be found in the tutorials.  as this work presents a'pipeline', tangible results are in the form of outputs. supporting arguments are in-line.  technological revolutions often drive and precede biological revolutions. the omics field has not been immune to this general rule. such paradigm shifts are often followed by a period of great adaptation. for massively parallel sequencing, developing curriculums to educate scientists with the proper skill sets will require some time. meanwhile, the life science community is in desperate need for tools to support scientists that have been trained prior to the sequencing of the human genome. although neat is not intended to replace thorough bioinformatics analysis per se, we believe that it provides helpful tools to accompany scientists in the analysis of ngs data and allow them to rapidly apply standard exploratory data analysis methods to assess the quality of their experiments within 24 h of the sequencing run completion. specifically, we strongly believe that providing wet-lab scientists with simple tools to facilitate rapid data visualization, which is a significant bottleneck for many users, will greatly benefit the community and will allow one to better plan and foresee biological experiments without the need to wait for thorough bioinformatics analysis. neat was developed for a wide audience including scientists with no a priori programming knowledge. to this end, although neat should be self explanatory, it comes with step-by-step tutorials as well as two test datasets that will enable novice users to follow through and reproduce entire chipseq and rnaseq workflows. in addition, given the wide diversity of interests in the life sciences, neat has been developed to be versatile, easily customizable and applicable to a wide variety of different genomes. finally, the modular structure of neat allows advanced users and computational core facilities to easily add and modify tasks, customize settings and comply with internal rules and regulations with minimal footprint to their existing server architecture. taken together, we believe neat will be of general interest and has the potential to be widely adopted for its versatility and ease of use. neat is an open-source software under an mit license. neat, including tutorials and test data, is publicly available on github. availability and requirements project home page: https://github.com/pschorderet/neat operating system: mac osx programming language: perl, r, applescript license: neat is an open-source software under an mit license additional files additional file 1: quick guide chipseq. step-by-step guide for the analysis of chipseq datasets, including the provided test dataset. additional file 2: quick guide rnaseq. step-by-step guide for the analysis of rnaseq datasets, including the provided test dataset. additional file 3: code architecture. architecture of the provided neat chipseq project after completion of all steps on the remote server. the color code highlights which files are created during which step as well as where they are stored. additional file 4: qc report. qc report generated by neat when running the chip- and rnaseq test data set. additional file 5: quick guide to add custom modules. step-by-step guide for the addition of custom modules. additional file 6: code architecture schematic. example of a module’s architecture in neat. the left part schematically represents the different steps that constitute each module. the right part represents some example code and how it is imbricated. the example reflects neat run on a torque manager system though neat can be run on other systems as well including lsf clsuters. additional file 7: code architecture. code architecture for the additional of custom modules. custom code should replace the red font. the module backbone as well as the submission procedures are robust, highly repetitive and will automatically manage job submission and queuing. competing interests the author declares no competing interests. ps is supported by an advanced swiss national foundation fellowship and is supported in part through the national institute of general medical sciences grant r gm48405- awarded to robert e kingston. i would like to acknowledge the kingston lab members for stimulating discussions, feedback and testing; particularly alan rodrigues, sharon marr, aaron plys, ozlem yildirim, ruslan sadreyev and bob kingston for critical reading during the preparation of the manuscript.
the analysis of next generation sequencing has become a standard task for many laboratories in the life sciences. to simplify the control of the workflow, neat projects are built around a unique and centralized file containing sample names, replicates, conditions, antibodies, alignment-, filtering- and peak calling parameters as well as cluster-specific paths and settings. in comparison to many publicly available tools including galaxy, neat provides three main advantages: through the development of double-clickable executables, neat is efficient, easy to implement and intuitive; storage space, maximum number of job submissions, wall time and cluster-specific parameters can be customized as neat is run on the institution’s cluster; neat allows users to visualize and summarize ngs data rapidly and efficiently using various built-in exploratory data analysis tools including metagenomic and differentially expressed gene analysis. here, we present the next generation analysis toolbox that allows non-expert users including wet-lab scientists to comprehensively build, run and analyze ngs data through double-clickable executables without the need of any programming experience.
 the analysis of next generation sequencing has become a standard task for many laboratories in the life sciences. though there exists several tools to support users in the manipulation of such datasets on various levels, few are built on the basis of vertical integration. here, we present the next generation analysis toolbox that allows non-expert users including wet-lab scientists to comprehensively build, run and analyze ngs data through double-clickable executables without the need of any programming experience.  in comparison to many publicly available tools including galaxy, neat provides three main advantages: through the development of double-clickable executables, neat is efficient, easy to implement and intuitive; storage space, maximum number of job submissions, wall time and cluster-specific parameters can be customized as neat is run on the institution’s cluster; neat allows users to visualize and summarize ngs data rapidly and efficiently using various built-in exploratory data analysis tools including metagenomic and differentially expressed gene analysis. to simplify the control of the workflow, neat projects are built around a unique and centralized file containing sample names, replicates, conditions, antibodies, alignment-, filtering- and peak calling parameters as well as cluster-specific paths and settings. moreover, the small-sized files produced by neat allow users to easily manipulate, consolidate and share datasets from different users and institutions.  neat provides biologists and bioinformaticians with a robust, efficient and comprehensive tool for the analysis of massive ngs datasets. frameworks such as neat not only allow novice users to overcome the increasing number of technical hurdles due to the complexity of manipulating large datasets, but provide more advance users with tools that ensure high reproducibility standards in the ngs era. neat is publically available at https://github.com/pschorderet/neat. electronic supplementary material the online version of this article contains supplementary material, which is available to authorized users. keywords bioinformaticsgenomicshigh throughput sequencingrnaseqchipseqngs pipelineshttp://dx.doi.org/ /100000057national institute of general medical sciences r gm48405-21swiss national foundationp300p3_158516schorderet patrick issue-copyright-statement© the author 2016 