Skip to content

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

259 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Logo


1. Introduction

Phage annotation tools use different algorithms and databases to annotate putative coding sequences. The next step typically involves manually merging the output files from these tools, which can be both time-consuming and prone to error.

We developed PhaGAMeToo within the NFDI4Microbiota framework to help scientists generate submission-ready phage annotation files.

PhaGAMeToo is a semi-automated workflow that merges phage genome annotations, improving phage genome analysis with a particular emphasis on enhancing functional annotation.

Workflow Diagram

Workflow of PhaGAMeToo

The workflow has a pre-step and three main steps:

  1. Step 0: Preparation of Directory Structure – user action required.
  2. Step 1: Merging Data from Pharokka and VIBRANT – no user action required.
  3. Step 2: Creating a GenBank File – no user action required.
  4. Step 3: Annotating Hypothetical Proteins Using BLASTP – some user action required.

Input and Output File Structure

The PhaGAMeToo workflow requires input files generated by Pharokka and VIBRANT (viral annotated GenBank and FASTA files). It is critical to provide the output files from Pharokka and VIBRANT beforehand, as the workflow itself does not perform viral or uncultivated viral genome annotation using these tools.

The directory organization is vital because the workflow matches the base names of the VIBRANT files with the base names of subdirectories found in the pharokka/ parent directory for each sample.


2. GitHub Contents

  1. Introduction
  2. GitHub Contents
  3. Installation Instructions
  4. Workflow Steps
  5. System Requirements and Usage
  6. Output Explanation
  7. Reference Genomes Analyzed
  8. Contributions

We recommend that users review the entire workflow documentation to understand its prerequisites and objectives before installing and running the workflow.

3. Installation Instructions

Users need to clone the repository on their local machine to start this workflow. To do that, follow these steps:

  1. Open your terminal.

  2. Navigate to the directory where you want to clone the repository.

  3. Run the following command:

git clone https://github.com/ebrar-7777/PhaGAMeToo

Alternatively, you can download a zipped repository from the "Code" button on GitHub, then unzip it in your desired location.

  1. At the top of the repository page, click on "Code" button,

  2. In the dropdown menu that appears, click on "Download ZIP". This will download the entire repository as a ZIP file to your computer and extract it to your desired location.

3.1 Dependencies

This workflow merges outputs from Pharokka and VIBRANT and uses BLASTP to further annotate hypothetical proteins.

  • Viral genome annotations using Pharokka and VIBRANT should be completed before running the workflow (installing these tools is not strictly required for the workflow itself).
  • BLAST+ must be installed to run the workflow locally.

VIBRANT

Available for local installation and online use; it produces .gbk and .ffn output files. For detailed information and a user guide on VIBRANT, you can visit VIBRANT's GitHub page.

VIBRANT is also available at CyVerse Discovery Environment.

Pharokka

For detailed information and a user guide on Pharokka, you can visit Pharokka's GitHub page.

Pharokka is also available at Galaxy Europe

Installing BLAST and Setting Up the Environment

For detailed information and a user guide on BLAST, you can visit BLAST's GitHub page.

Installing BLAST Tool

Downloading BLAST:

  • Open your web browser and navigate to the NCBI BLAST+ download page

  • Download the appropriate version (preferably the LATEST version) of the BLAST+ tool for your operating system (e.g., ncbi-blast-2.11.0+-x64-linux.tar.gz). You can either download the file or use wget:

wget https://ftp.ncbi.nlm.nih.gov/blast/executables/LATEST/ncbi-blast-*.tar.gz # zipped files of BLAST tool
wget https://ftp.ncbi.nlm.nih.gov/blast/executables/LATEST/ncbi-blast-*.tar.gz.md5 # checksum to verify download integrity
  • You can additonally check the integrity of the downloaded files using
md5sum -c ncbi-blast-*+-x64-linux.tar.gz.md5

Which should give you a terminal output similar to this:

ncbi-blast-*+-x64-linux.tar.gz: OK

Extracting the Downloaded File:

  • Open a terminal and navigate to the directory where the BLAST+ file was downloaded:
cd /path/to/downloaded_files

Make sure you replace <path/to/downloaded_files> with the actual path to your directory where your downloaded files are located.

  • Extract the .tar.gz file:
tar -zxvf ncbi-blast-*.tar.gz

Locating the BLAST+ bin Directory:

  • After extraction, navigate to the extracted BLAST directory. This directory will contain the bin directory with the BLAST executables.

Place the bin Directory in the PhaGAMeToo Directory

Moving to the PhaGAMeToo Directory:

  • Navigate to the PhaGAMeToo directory :
cd /path/to/PhaGAMeToo

Make sure you replace <path/to/PhaGAMeToo> with the actual path to your PhaGAMeToo directory.

Move the bin Directory:

  • Move or copy the bin directory from the extracted BLAST directory to the PhaGAMeToo directory. Use the full path to the extracted bin directory and specify the destination directory:
# Copy the bin directory
cp -r /path/to/extracted/blast/bin /path/to/PhaGAMeToo/bin/
# Move the bin directory
mv /path/to/extracted/blast/bin /path/to/PhaGAMeToo/

This setup ensures that the necessary BLAST executables are available within your PhaGAMeToo directory, making it easy to run BLAST commands from within the project environment.

You can verify the use of BLAST in the directory by navigating to the PhaGAMeToo directory and opening the usage documentation for BLASTP.

cd /path/to/PhaGAMeToo/
bin/blastp -help

Which should give you an output similar to this:

# terminal output, do not copy into your terminal
$ bin/blastp -help
USAGE
  blastp [-h] [-help] [-import_search_strategy filename]
    [-export_search_strategy filename] [-task task_name] [-db database_name]
    [-dbsize num_letters] [-gilist filename] [-seqidlist filename]
    [-negative_gilist filename] [-negative_seqidlist filename]
    [-taxids taxids] [-negative_taxids taxids] [-taxidlist filename]
    [-negative_taxidlist filename] [-no_taxid_expansion] [-ipglist filename]
    [-negative_ipglist filename] [-entrez_query entrez_query]
    [-db_soft_mask filtering_algorithm] [-db_hard_mask filtering_algorithm]
    [-subject subject_input_file] [-subject_loc range] [-query input_file]
    [-out output_file] [-evalue evalue] [-word_size int_value]
    [-gapopen open_penalty] [-gapextend extend_penalty]
    [-qcov_hsp_perc float_value] [-max_hsps int_value]
    [-xdrop_ungap float_value] [-xdrop_gap float_value]
    [-xdrop_gap_final float_value] [-searchsp int_value] [-seg SEG_options]
    [-soft_masking soft_masking] [-matrix matrix_name]
    [-threshold float_value] [-culling_limit int_value]
    [-best_hit_overhang float_value] [-best_hit_score_edge float_value]
    [-subject_besthit] [-window_size int_value] [-lcase_masking]
    [-query_loc range] [-parse_deflines] [-outfmt format] [-show_gis]
    [-num_descriptions int_value] [-num_alignments int_value]
    [-line_length line_length] [-html] [-sorthits sort_hits]
    [-sorthsps sort_hsps] [-max_target_seqs num_sequences]
    [-num_threads int_value] [-mt_mode int_value] [-ungapped] [-remote]
    [-comp_based_stats compo] [-use_sw_tback] [-version]

DESCRIPTION
   Protein-Protein BLAST 2.15.0+

4. Workflow Steps

The workflow includes four steps:

  1. Preparation of Directory Structure
  2. Merging Data from Pharokka and VIBRANT
  3. Creating a GenBank File
  4. Annotating Hypothetical Proteins Using BLASTP

4.0 Preparation of Directory Structure

For proper organization and functionality of the PhaGAMeToo workflow, it is essential to manually place the output files and directories generated by Pharokka and VIBRANT in their corresponding directories. Here is how to do it:

  1. The PhaGAMeToo directory contains subdirectories for storing output files and directories generated by various tools, including:
  • pharokka
  • VIBRANT
  1. Pharokka Outputs:
  • The pharokka directory is intended to store output directories generated by the Pharokka annotation tool.

  • After running Pharokka, move or copy the Pharokka output directories manually into the pharokka directory within PhaGAMeToo, or use the following command:

mv /path/to/pharokka/output/directory /path/to/PhaGAMeToo/pharokka/

The files inside the Pharokka output directory are named phanotate.ffn (name depends on the algorithm used for annotation using pharokka, could also be prodigal-gv.ffn, etc.) and pharokka.gbk. These file names should match, as shown below:

Workflow Diagram

To rename the "phanotate.ffn" file to "pharokka.ffn" for all files in the Pharokka directory, use the following command:

find /path/to/main/directory -type f -name "phanotate.ffn" -execdir mv {} pharokka.ffn \;

We recommend users first perform genome annotation with Pharokka. If a terminase large subunit is identified, continue using the Pharokka re-orientation mode and perform VIBRANT on the re-oriented genome starting with the terminase large subunit coding gene (TerL).

Pharokka directory structure

The final pharokka directory structure should look like this:

~/path/to/cloned/directory/PhaGAMeToo/$ ls pharokka/
NODE_14_length_32758_cov_27.286243  NODE_3_length_46326_cov_8.847939
NODE_23_length_33953_cov_17.236769  NODE_7_length_50901_cov_15.681214
NODE_34_length_35563_cov_8.221894

Listing the contents of each subdirectory should resemble the following:

~/path/to/cloned/directory/PhaGAMeToo/$ ls pharokka/*
NODE_14_length_32758_cov_27.286243:
pharokka.ffn  pharokka.gbk

NODE_23_length_33953_cov_17.236769:
pharokka.ffn  pharokka.gbk

NODE_34_length_35563_cov_8.221894:
pharokka.ffn  pharokka.gbk

NODE_3_length_46326_cov_8.847939:
pharokka.ffn  pharokka.gbk

NODE_7_length_50901_cov_15.681214:
pharokka.ffn  pharokka.gbk

  1. VIBRANT Outputs:
  • The VIBRANT directory is intended to store individual output files generated by the VIBRANT annotation tool, including .gbk (GenBank) and .ffn (nucleotide FASTA) files.

  • After running VIBRANT, locate the generated .gbk and .ffn files, and move or copy them into the VIBRANT directory within PhaGAMeToo manually, or use the following command:

mv /path/to/VIBRANT/output/file.gbk /path/to/VIBRANT/output/file.ffn /path/to/PhaGAMeToo/VIBRANT/.

VIBRANT directory structure

The files in the VIBRANT directory must be named according to the sample, with appropriate extensions, such as NODE_7_length_50901_cov_15.681214.gbk and NODE_7_length_50901_cov_15.681214.ffn. The directory structure should look like this:

~/path/to/cloned/directory/PhaGAMeToo/$ ls VIBRANT/
NODE_14_length_32758_cov_27.286243.ffn  NODE_34_length_35563_cov_8.221894.gbk
NODE_14_length_32758_cov_27.286243.gbk  NODE_3_length_46326_cov_8.847939.ffn
NODE_23_length_33953_cov_17.236769.ffn  NODE_3_length_46326_cov_8.847939.gbk
NODE_23_length_33953_cov_17.236769.gbk  NODE_7_length_50901_cov_15.681214.ffn
NODE_34_length_35563_cov_8.221894.ffn   NODE_7_length_50901_cov_15.681214.gbk

After that, the names of the .ffn and .gbk files inside the VIBRANT directory should be the same as the names of the subdirectories in the Pharokka parent directory, as shown in the code examples above or the images below:


Workflow Diagram
Workflow Diagram


We encourage users to always keep a backup copy of their input data in a separate location.

4.1 Merging Data (Pharokka + VIBRANT)

This is an automated step, no user action required.

This step formats the input files and combines annotations from Pharokka and VIBRANT to produce the final functional annotation of viral genomes (DNA or RNA). The final annotations are presented in CSV files. To merge the data, files with the .gbk and .ffn extensions from each tool must be placed in their respective directories, as described above.

4.2 Creating a GenBank File

This is an automated step, no user action required.

Once the final functional annotations are available in CSV files, the next step is to compile them into a comprehensive GenBank file. For each CSV file containing the final functional annotation results, a GenBank file is created using the data from the initial .gbk file.

4.3 Annotating Hypothetical Proteins Using BLASTP

Some user action required:

After updating the script with the desired BLAST databases and placing Pharokka/VIBRANT outputs in the correct directories, you can run the workflow.


5. System requirements and usage

A typical Linux desktop can run this workflow, provided you have sufficient storage space. The required amount of storage depends on both the number of genomes you plan to annotate and the databases you wish to use.

(Optional) We recommend running the workflow in a dedicated conda environment, as some necessary packages may not come pre-installed on your operating system. You can find more information on installing and using Anaconda in its official documentation found here.

Usage : Only a single command will be sufficient for running steps 1, 2 and 3 of the workflow:

python PhaGAMeToo.py -f VIBRANT/ -s pharokka/ -o out -gbk -n <NUM_CORES>

The available options for this command are as follows:

  -h, --help            show this help message and exit
  -d, --dna             Use DNA comparison (default)
  -r, --rna             Use RNA comparison
  -f FOLDER1, --folder1 FOLDER1
                        First folder containing GBK and FFN files
  -s FOLDER2, --folder2 FOLDER2
                        Second folder containing GBK and FFN Subfolders
  -gbk                  Gives GBK output (default: False)
  -o OUTPUT, --output OUTPUT
                        Output folder path (default: current directory)
  -n NUM_CORES, --num_cores NUM_CORES
                        Number of cores to be used in the alignment process

In the process of the workflow execution, three scripts are executed in this way:

  1. locustag_fix.py: This script standardizes and formats the .gbk and .ffn files from both Pharokka and VIBRANT, ensuring uniformity and readiness for processing. It then stores the files in this new format,
  2. PhaGAMeToo.py: This script compares and merges the output files from Pharokka and VIBRANT into CSV files and a single .gbk file. It also calls locustag_fix.py and progress.py,
  3. progress.py: This script uses BLASTP to align identified hypothetical proteins against the databases specified by the user.

5.1 Important notes

  1. Genome orientation can be verified by checking the orientation (positive or negative strand) of the terminase large subunit (TerL).

    Genomes can be reoriented to start at the terminase large subunit gene by using the Pharokka reorientation mode whenever needed. The resulting FASTA file can then be used directly as input for VIBRANT.

    To reorient the genome so that it begins with the large terminase subunit, use the --terminase command along with:

    --terminase_strand – Specifies whether the large terminase subunit is on the pos (positive) or neg (negative) strand.
    --terminase_start – Defines the coordinate at which the large terminase subunit begins.

    For example, if you determine (after annotating with Pharokka) that the large terminase subunit starts at position 1111 on the positive strand, you could run:

    pharokka.py -i <fasta file> -o <output folder> -d <path/to/database_dir> -t <threads>  --terminase --terminase_start 1111 --terminase_strand pos 

    Alternatevely, you can use the --dnaapler flag provided by Pharokka. This process automatically detects and reorients the genome to start with the large terminase subunit. For more information, visit the dnaapler page

    pharokka.py -i <fasta file> -o <output folder> -d <path/to/database_dir> -t <threads> --dnaapler
  2. The SwissProt, NCBI non-redundant, and RefSeq Protein databases were used to evaluate the BLAST analysis provided by PhaGAMeToo. Additional databases are recommended, but they depend on the available computer resources, mainly storage and CPU cores available. Users can include other databases in the progress.py script (see 5.2 Downloading BLAST Databases and 5.3 Updating The Script).

  3. The workflow is designed to run in parallel, based on the number of CPUs the user submits under the -n/--num_cores flag.

5.2 Downloading BLAST Databases

5.2.1 Navigate to the NCBI BLAST Database Directory

5.2.2 Select and Download the Desired .tar.gz Database Files

  • Download the desired .tar.gz database files (for example, swissprot, nr, env_nr, 'etc.' ) to your local machine.
chmod +x path/to/PhaGaMeToo/bin/update_blast.pl # change persmissions
mkdir path/to/PhaGAMeToo/db/<database_name> # create directory, names: swissprot, nr, env_nr
path/to/PhaGAMeToo/bin/update_blastdb.pl --decompress nr # ~ size 563 Gb as of 2024-08-05
path/to/PhaGAMeToo/bin/update_blastdb.pl --decompress swissprot #~ size 600 Mb as of 2024-08-05
path/to/PhaGAMeToo/bin/update_blastdb.pl --decompress env_nr #~ size 5 Gb as of 2024-08-05

Make sure you replace <path/to/PhaGAMeToo/bin/> with the actual path to your PhaGAMeToo bin directory that contains BLAST+ scripts. Make sure you replace <path/to/PhaGAMeToo/db/> with the actual path to your PhaGAMeToo db directory. Make sure you replace <database_name> with the name of your database.

Keep in mind, that using BLAST+ with the "nr" database might not be suitable for local machines (like laptops) due to it's size (563 Gb, download about 11 hours, at average download speed 14.1 Mb/s), while downloading the "swissprot" and "env_nr" only takes a few minutes.

5.3 Updating The Script

Update the dbs List in the progress.py Script

  • Update the dbs array in the progress.py script file to include the names of the newly extracted databases. For example:
#########################################################
# Here you can alter the databases you want to use for alignment
# if only one database is listed, it is the only one that will be used
# results of all hits are generated per database
# first hits contain all databases first hits in one file 
dbs = ['swissprot', 'nr', 'refseq-protein', <database_name>]
##########################################################

Remember to replace <database_name> with the actual file names of the databases you are downloading and extracting.

It is recommended that users check the PhaGAMeToo directory to ensure their setup correctly mirrors the demonstrated structure.

IMPORTANT NOTE:

Make sure the script correctly points to the database directory where the databases are stored. If you are using a HPC, that already has the databases installed, you just need to place the paths in the progress.py script.

#################################################################################
# you can permenantly store the locations of your databases here, and just change the dbs list
# you only need to alter this list once, 
# important note, the "{db}*" at the end here is an integral part of the script and must remain as is
list_of_db = [
f"/path/to/your/database/database1/{db}*", # example --> f"data/db/ncbi/blast/db/refseq_protein/2018-09-07/{db}*
f"/path/to/your/database/database2/{db}*", # example --> f"data/db/ncbi/blast/db/nr/latest/2018-09-07/{db}*
f"/path/to/your/database/database3/{db}*" # example --> f"data/db/ncbi/blast/db/swissprot/2024-08-08//{db}*
] 
#################################################################################

The user needs to make sure, that the names of files in the {db}* directory match the name listed in the dbs array. Do not change the "/{db}*" at the end, as the scripts uses it to verify the locations of database files, taken from the dbs array of databases.

Performance Benchmarks

The workflow was tested on the EVE cluster (Helmholtz Centre for Environmental Research (UFZ)). Sample sizes were selected using the random module from the Python 3 library, with seed(123) on 56 uVIGs as the core set.

  • 3 x 5 uVIGs (average number of hypothetical proteins processed = 245)
  • 3 x 10 uVIGs (average number of hypothetical proteins processed = 517)
  • 3 x 20 uVIGs (average number of hypothetical proteins processed = 931)
  • 3 x 30 uVIGs (average number of hypothetical proteins processed = 1461)
  • 3 x 40 uVIGs (average number of hypothetical proteins processed = 2003)
  • 3 x 50 uVIGs (average number of hypothetical proteins processed = 2482)

Based on the CPU times logged by the cluster and the varying number of hypothetical proteins processed from the sample sizes (keep in mind that every uVIG does not hold the same number of hypothetical proteins), we observed a range from 214 (the lowest) to 2487 (the highest). We created a linear regression model with interactions as follows:

lm_interactions <- lm(CPU_time ~ number_of_hypothetical_proteins_processed * db_name)

The model has shown that using our testing configuration (56 CPUs with 8 GB of RAM per CPU):

  1. Using SwissProt, RefSeq-protein, and NCBI non-redundant database (allDB), it takes approximately 2333 seconds of CPU time per additional hypothetical protein (R²: 0.9999).
  2. Using the NCBI non-redundant database, it takes approximately 1969 seconds of CPU time per additional hypothetical protein (R²: 0.9996).
  3. Using the RefSeq-protein database, it takes approximately 365 seconds of CPU time per additional hypothetical protein (R²: 0.9996).
  4. Using the SwissProt database, it takes approximately 1.6 seconds of CPU time per additional hypothetical protein (R²: 0.9998).

Using this linear regression model, we can somewhat predict the CPU time required to process 5000 hypothetical proteins depending on the database in use. The predicted CPU times are as follows:

  1. allDB → 3240 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
  2. NCBI non-redundant → 2735 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
  3. RefSeq-protein → 506 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
  4. SwissProt → 2 hours 14 minutes of predicted CPU time for 5000 hypothetical proteins at the current configuration

Linear regression prediction model with interactions

The image above represents a linear model plot, where the red dots represent the datapoints, obtained during our testing of the workflow (that is, the number of hypothetical proteins processed, their correspoinding CPU time, based on databased used for alignment.

Additionally, using the Max RAM (GB), which is the maximal amount of RAM used in the process, we calculated the minimal required RAM per CPU core necessary to execute the workflow in this way:

min RAM = (Max RAM (GB)*Total RAM per CPU)/ Total Available RAM (GB) 

We have calculated the minimal RAM requirements as follows:

  1. allDB - calculated as 4.04 GB per core, rounded up to 5 GB
  2. NCBI non-redundant - calculated as 4.04 GB per core, rounded up to 5 GB
  3. RefSeq-protein - calculated as <1 GB per core, rounded up to 1 GB
  4. SwissProt - calculated as <1 GB per core, rounded up to 1 GB

Lastly, the authors of this workflow suggest that for allDB (that is, the NCBI non-redundant database in combination with any other database) or the NCBI non-redundant database by itself, users should split their viral genomes or uVIGs into batches of around 60 samples.

For our testing purposes, we used the SwissProt, RefSeq-protein, and NCBI non-redundant database on 56 uVIGs (encompassing 2782 hypothetical proteins), which took 1796.41 CPU hours, resulting in a real-time of 33 hours, 58 minutes, and 50 seconds. The total CPU usage was 97.6%, indicating that around 55 CPUs were needed for the annotation, using an average of 4.04 GB of RAM per CPU core.

Additionally, we tested the merging times of 7 Huge Wastewater genomes, described by Kallies et al. (2023). We used the same testing configuration as descibed above (56 CPUs with 8 GB of RAM per CPU), without the additional annotation using BLAST. All merging procedures were conducted on the EVE cluster (Helmholtz Centre for Environmental Research (UFZ)).

We present the results here:

Number of run JobID Elapsed time EVE Node
1 12_WW_phages-30490252 91.31 node024
2 12_WW_phages-30490269 91.16 node024
3 12_WW_phages-30490272 88.59 node024
4 12_WW_phages-30490281 85.81 node024
5 12_WW_phages-30490283 85.18 node024
6 12_WW_phages-30490284 85.18 node024
7 12_WW_phages-30490290 84.38 node024
8 12_WW_phages-30490291 87.94 node024
9 12_WW_phages-30490302 85.23 node024
10 12_WW_phages-30490599 85.72 node024
Average -- 87.05 --

6. Output Explanation

When the script finishes, two main outputs are created:

  1. An output directory (named by the user, e.g., -o out) containing the Outputs folder
  2. A BLAST directory

6.1 Outputs Directory

The "<out_directory_name>/Outputs" directory contains two subdirectories "CSV_data" and "GBK_data".

~/path/to/cloned/directory/PhaGAMeToo/<out_directory_name>/Outputs/$ ls
error_dna_array.txt  CSV_data  GBK_data

CSV data

The "out/Outputs/CSV_data" directory contains separate subdirectories, one for each viral genome or uVIG (taken from pharokka subdirectory names), which in turn have these CSV files:

  • The '<pharokka_directory_name>_compared_CDS.csv' contains information on locus_tag, product, translation and nucleotide sequence of both VIBRANT (File1_*) and pharokka (File2_*) annotation tools. It only shows coding sequences that could be matched and compared between the two tools and were considered for the final annotation. The last two columns, that is, the longest_locus_tag and final_product (final annotation) are used in the final GenBank file found in the out/Outputs/GBK_data directory,
  • The '<pharokka_directory_name>_unmatched_CDS.csv' contains information on locus_tag, product, translation and nucleotide sequence of coding regions that could not be matched and compared between VIBRANT and pharokka annotation tools,
  • The final functional annotation results are displayed on the '<pharokka_directory_name>_all_CDS.csv' sheet in the excel file. The "Longest_locus_tag" column holds the name of the CDS used in the final annotation along with the corresponding functional annotation, found under the "Final_product" column. An example on how the '<pharokka_directory_name>_all_CDS.csv' looks like can be found bellow:

Tab-Delimited File

GBK data

The out/Outputs/GBK_data directory contains separate, submission ready GenBank files (.gbk extension) with the functional annotations, one for each submitted viral sequence or uVIG. An example of one can be found bellow:

Genbank File

error_dna_array.txt

The file contains any CDS sequence, that was found to hold one or more "N" nucleotide in the sequence in this maner:

~/path/to/cloned/directory/PhaGAMeToo/<out_directory_name>/Outputs$ cat error_dna_array.txt | head -10
File:pharokka/NODE_10_length_50650_cov_22.118688/pharokka.ffn 
Node: >NODE_10_length_50650_cov_22_118688_CDS_0041 hypothetical protein
Error DNA Array: ACCATCGACGTGAACGTGGAGGANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
----------------------------------------------------------------------

File:pharokka/NODE_16_length_43363_cov_34.372887/pharokka.ffn 
Node: >NODE_16_length_43363_cov_34_372887_CDS_0067 hypothetical protein
Error DNA Array: CTGCTGCAGGCCGAGTTCANNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
----------------------------------------------------------------------

6.2 BLAST Directory

The BLAST directory contains three subdirectories as shown in the example bellow:

BLAST folder content

~/path/to/cloned/directory/PhaGAMeToo/BLAST/$ ls
all_hits  first_hits  hypothetical_proteins
  • "BLAST/all_hits" - contains directories named after subdirectories found in the input pharokka/ directory. Each of the subdirectories holds one or more files that are the outputs of the "BLASTP" tool. The additional annotation files are generated by blasting hypothetical proteins (identified as such by pharokka and VIBRANT, sequences found in "BLAST/hypothetical_proteins") against the user requested database(s),
  • "BLAST/first_hits" - contains subdirectories named after subdirectories contained in the input pharokka/ direcory. Each of the subdirectories holds a file named "data". The data file holds only the best hits from each of the CDS annotations found as separate files in /BLAST/all_hits/ combined in a single file,
  • "BLAST/hypothetical_proteins" - contains subdirectories named after subdirectories contained in the input pharokka/ direcory. Each of the subdirectories hold one or more protein fasta files, with the protein sequence of the hypothetical protein. The protein fasta sequence is used in the blastp alignment agains the user requested database(s). The fasta files can be used for further processing.

7. Reference Genomes Analyzed

The following genomes were analyzed using PhaGAMeToo as reference genomes:

Enterobacteria phage MS2 isolate ST4, complete genome - GenBank accession number: EF204940.1

MAG: Prevotella phage Lak-C1, complete genome - GenBank accession number: MK250029.1

Enterobacteria phage T4, complete genome - GenBank accession number: NC_000866.4

Escherichia phage phiX174, complete genome - GenBank accession number: NC_001422.1

8. Contributions

We welcome contributions to this project and appreciate your interest in improving it. To ensure a smooth process for everyone, please follow these guidelines:

Getting Started

  1. Fork the repository by clicking the "Fork" button at the top right of this repository.
  2. Clone your fork to your local machine.
  3. Create a new branch for your feature or bugfix.

Making Changes

  1. Ensure code quality by keeping your code clean and well-documented. Follow the existing code style and conventions.
  2. Write tests if applicable to ensure your changes work as expected.
  3. Commit your changes with a clear and descriptive message.

Submitting Changes

  1. Push your branch to your fork on GitHub.
  2. Create a Pull Request on the original repository.
  • Provide a clear title and description for your pull request.
  • Reference any related issues (e.g., "Fixes #123").

Code Review Process

  • Your pull request will be reviewed by the project maintainers.
  • They may request changes or ask questions.
  • Please be responsive and address any feedback in a timely manner.

Reporting Issues

If you encounter a bug or have a feature request, please open an issue:

  • Go to the "Issues" tab of the repository.
  • Click on "New Issue".
  • Provide a clear and descriptive title.
  • Include as much relevant information as possible.

Community Standards

Be respectful and considerate in all interactions.

Thank you for your contributions!

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages