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.
The workflow has a pre-step and three main steps:
- Step 0: Preparation of Directory Structure – user action required.
- Step 1: Merging Data from Pharokka and VIBRANT – no user action required.
- Step 2: Creating a GenBank File – no user action required.
- Step 3: Annotating Hypothetical Proteins Using BLASTP – some user action required.
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.
- Introduction
- GitHub Contents
- Installation Instructions
- Workflow Steps
- System Requirements and Usage
- Output Explanation
- Reference Genomes Analyzed
- Contributions
We recommend that users review the entire workflow documentation to understand its prerequisites and objectives before installing and running the workflow.
Users need to clone the repository on their local machine to start this workflow. To do that, follow these steps:
-
Open your terminal.
-
Navigate to the directory where you want to clone the repository.
-
Run the following command:
git clone https://github.com/ebrar-7777/PhaGAMeTooAlternatively, you can download a zipped repository from the "Code" button on GitHub, then unzip it in your desired location.
-
At the top of the repository page, click on "Code" button,
-
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.
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.
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.
For detailed information and a user guide on Pharokka, you can visit Pharokka's GitHub page.
Pharokka is also available at Galaxy Europe
For detailed information and a user guide on BLAST, you can visit BLAST's GitHub page.
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 usewget:
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.md5Which should give you a terminal output similar to this:
ncbi-blast-*+-x64-linux.tar.gz: OKExtracting the Downloaded File:
- Open a terminal and navigate to the directory where the BLAST+ file was downloaded:
cd /path/to/downloaded_filesMake sure you replace <path/to/downloaded_files> with the actual path to your directory where your downloaded files are located.
- Extract the
.tar.gzfile:
tar -zxvf ncbi-blast-*.tar.gzLocating the BLAST+ bin Directory:
- After extraction, navigate to the extracted BLAST directory. This directory will contain the
bindirectory with the BLAST executables.
Moving to the PhaGAMeToo Directory:
- Navigate to the
PhaGAMeToodirectory :
cd /path/to/PhaGAMeTooMake sure you replace <path/to/PhaGAMeToo> with the actual path to your PhaGAMeToo directory.
Move the bin Directory:
- Move or copy the
bindirectory from the extracted BLAST directory to thePhaGAMeToodirectory. Use the full path to the extractedbindirectory 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 -helpWhich 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+The workflow includes four steps:
- Preparation of Directory Structure
- Merging Data from Pharokka and VIBRANT
- Creating a GenBank File
- Annotating Hypothetical Proteins Using BLASTP
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:
- The PhaGAMeToo directory contains subdirectories for storing output files and directories generated by various tools, including:
pharokkaVIBRANT
- 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:
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).
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
- 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/.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.gbkAfter 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:
We encourage users to always keep a backup copy of their input data in a separate location.
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.
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.
Some user action required:
- Manually set the databases for BLASTP alignment (see 5.2 Downloading BLAST Databases and 5.3 Updating The Script).
- Update any needed paths in
progress.pyfor your system.
After updating the script with the desired BLAST databases and placing Pharokka/VIBRANT outputs in the correct directories, you can run the workflow.
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 processIn the process of the workflow execution, three scripts are executed in this way:
- 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,
- 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,
- progress.py: This script uses BLASTP to align identified hypothetical proteins against the databases specified by the user.
-
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
-
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).
-
The workflow is designed to run in parallel, based on the number of CPUs the user submits under the -n/--num_cores flag.
- Open your web browser and go to the NCBI BLAST database directory.
- Download the desired
.tar.gzdatabase 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-05Make 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.
- Update the
dbsarray in theprogress.pyscript 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.
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.
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):
- 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).
- Using the NCBI non-redundant database, it takes approximately 1969 seconds of CPU time per additional hypothetical protein (R²: 0.9996).
- Using the RefSeq-protein database, it takes approximately 365 seconds of CPU time per additional hypothetical protein (R²: 0.9996).
- 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:
- allDB → 3240 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
- NCBI non-redundant → 2735 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
- RefSeq-protein → 506 hours of predicted CPU time for 5000 hypothetical proteins at the current configuration
- SwissProt → 2 hours 14 minutes of predicted CPU time for 5000 hypothetical proteins at the current configuration
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:
- allDB - calculated as 4.04 GB per core, rounded up to 5 GB
- NCBI non-redundant - calculated as 4.04 GB per core, rounded up to 5 GB
- RefSeq-protein - calculated as <1 GB per core, rounded up to 1 GB
- 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 | -- |
When the script finishes, two main outputs are created:
- An output directory (named by the user, e.g.,
-o out) containing theOutputsfolder - A
BLASTdirectory
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_dataThe "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:
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:
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
----------------------------------------------------------------------The BLAST directory contains three subdirectories as shown in the example bellow:
~/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.
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
We welcome contributions to this project and appreciate your interest in improving it. To ensure a smooth process for everyone, please follow these guidelines:
- Fork the repository by clicking the "Fork" button at the top right of this repository.
- Clone your fork to your local machine.
- Create a new branch for your feature or bugfix.
- Ensure code quality by keeping your code clean and well-documented. Follow the existing code style and conventions.
- Write tests if applicable to ensure your changes work as expected.
- Commit your changes with a clear and descriptive message.
- Push your branch to your fork on GitHub.
- 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").
- 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.
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.
Be respectful and considerate in all interactions.
Thank you for your contributions!








