Address of the bookmark: https://github.com/legumeinfo/gcv

Features

• Circular and linear views of genomes

• Capable of drawing genomes up to 10 Mbp with 1000's of features and 100's contigs

• Smooth zooming down to the sequence level

• Easily generate features and plots directly form the sequence (e.g. ORFs, GC-content and GC-Skew)

• Save high resolution PNG maps up to 8000x8000px

• Fully documented API for interacting with CGView.js maps

Address of the bookmark: https://js.cgview.ca/

What is Genome Assembly?

Genome assembly involves piecing together short DNA sequence reads generated by sequencing platforms (e.g., Illumina, PacBio, Oxford Nanopore) into longer, contiguous sequences called contigs. This can be performed as:

• De Novo Assembly: Without a reference genome.
• Reference-Guided Assembly: Using a reference genome to guide the assembly process.

Step 1: Preparing Your Data

Before starting the assembly, ensure that your raw sequencing data is high quality.

1. Input Data

   • Short Reads: Illumina sequencing generates short, accurate reads ideal for scaffolding.
   • Long Reads: PacBio and Nanopore sequencing provide long reads for resolving repetitive regions.

2. Quality Control (QC)
   Use tools like FastQC or MultiQC to assess the quality of your reads:

   fastqc reads.fastq multiqc .

   Look for issues like low-quality bases, adapter contamination, or overrepresented sequences.

3. Read Trimming and Filtering
   Trim low-quality bases and adapters using Trimmomatic or Cutadapt:

   trimmomatic PE reads_R1.fastq reads_R2.fastq trimmed_R1.fastq trimmed_R2.fastq \ ILLUMINACLIP:adapters.fa:2:30:10 LEADING:3 TRAILING:3 SLIDINGWINDOW:4:20 MINLEN:36

Step 2: Choosing an Assembly Strategy

Select an assembly strategy based on your data type:

• Short-Read Assemblers:

  • SPAdes: Popular for microbial genomes.
  • Velvet: Fast for smaller genomes.

• Long-Read Assemblers:

  • Canu: Ideal for long-read datasets.
  • Flye: Versatile for small and large genomes.

• Hybrid Assemblers:

  • MaSuRCA: Combines short and long reads.
  • Unicycler: Optimized for bacterial genomes.

Step 3: Running the Assembly

3.1. SPAdes (Short-Read Assembly)

SPAdes is an excellent choice for small genomes, such as bacteria.

The output includes assembled contigs (contigs.fasta) and scaffolds (scaffolds.fasta).

3.2. Canu (Long-Read Assembly)

Canu is designed for high-error long reads from PacBio or Nanopore.

The output will be in canu_output/genome.contigs.fasta.

3.3. Hybrid Assembly with Unicycler

Unicycler combines short and long reads for improved assemblies.

Step 4: Assessing Assembly Quality

After assembly, evaluate its quality using the following tools:

1. QUAST
   QUAST generates assembly statistics, such as N50, genome size, and GC content:

   quast contigs.fasta -o quast_output

2. BUSCO
   BUSCO checks genome completeness by identifying conserved genes:

   busco -i contigs.fasta -o busco_output -l fungi_odb10 -m genome

3. Assembly Graph Visualization
   Visualize assembly graphs with Bandage:

   Bandage load assembly_graph.gfa

Step 5: Post-Assembly Steps

1. Polishing
   Improve assembly accuracy using tools like Pilon (for short reads) or Racon (for long reads).

   racon long_reads.fasta mapped_reads.sam contigs.fasta > polished_contigs.fasta

2. Scaffolding
   Link contigs into scaffolds using tools like SSPACE or Opera-LG if required.

3. Annotation
   Annotate the assembled genome using Prokka for prokaryotes or Maker for eukaryotes.

   prokka --outdir annotation_output --prefix genome contigs.fasta

Step 6: Sharing and Archiving

1. Submit to Public Repositories
   Share your assembly in databases like NCBI GenBank, ENA, or DDBJ.

2. Metadata Preparation
   Include detailed metadata for your submission, such as organism name, sequencing platform, and coverage.

Best Practices

• Always perform quality checks at each stage to ensure data integrity.
• Use multiple tools to cross-validate results when working with complex genomes.
• Document parameters and software versions for reproducibility.

Conclusion

Genome assembly is a powerful process that transforms raw sequencing data into a coherent representation of an organism’s genome. By following this step-by-step guide, you can successfully assemble genomes and uncover valuable biological insights. Whether you’re assembling a microbial genome or tackling the complexities of a eukaryotic genome, these tools and strategies will set you on the path to success.

Key Findings:

1. Chromosomal Fusion and Its Molecular Signature:

   • The fusion site is located at 2q13–2q14.1 and is characterized by degenerate telomeric sequences appearing interstitially, indicating the historical head-to-head joining of ancestral chromosomes.
   • Despite being a signature of a past fusion event, these telomeric repeats are no longer functional and have undergone sequence degradation over time.

2. Extensive Duplications in the Surrounding Genomic Region:

   • The study identifies large-scale segmental duplications flanking the fusion site, with several of these regions duplicated and scattered across multiple chromosomes.
   • These duplications are predominantly located in subtelomeric and pericentromeric regions, suggesting their role in genomic instability and chromosomal evolution.

3. Paralogous Regions and Their Evolutionary Relationships:

   • A 168-kilobase (kb) segment near the fusion site has 98%–99% sequence identity with three regions on chromosome 9 (9pter, 9p11.2, and 9q13).
   • Another 67-kb region distal to the fusion site shows a high degree of homology to sequences in chromosome 22qter.
   • Additionally, a 100-kb segment exhibits 96% sequence identity with a region in chromosome 2q11.2.

4. Comparative Genomics and Evolutionary Implications:

   • By comparing the duplicated sequences and their arrangement in primates, the researchers traced the order of duplication events leading to their present distribution.
   • The presence of specific repetitive elements within these duplicated segments serves as evolutionary markers that help infer their historical rearrangements.
   • Some of these duplicated regions are associated with chromosomal inversion breakpoints, potentially contributing to evolutionary changes in primates.
   • Recurrent structural rearrangements in these regions have been linked to human chromosomal disorders.

Conclusions and Implications:

• The findings provide valuable insights into the structural evolution of human chromosome 2, which played a crucial role in human speciation.
• Understanding these segmental duplications and their evolutionary trajectories sheds light on genomic instability, which may contribute to human genetic diseases.
• The study highlights how large-scale chromosomal rearrangements, such as fusion and duplication, have influenced the evolutionary divergence of humans from other primates.

This research advances our understanding of human genome evolution and offers a foundation for studying the effects of structural variants in genetic disorders.

Address of the bookmark: https://bioinfo.noble.org/GWASPRO/

Compare structural and functional annotations of proteins between sequenced genomes.

Address of the bookmark: http://frodock.chaconlab.org/

More at http://bmbl.sdstate.edu/DMINDA2/

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4086085/

Address of the bookmark: http://bmbl.sdstate.edu/DMINDA2/

Address of the bookmark: http://huanglab.phys.hust.edu.cn/hnadock/

The following table shows SLURM commands on the SOE cluster.

For more information, run man on the commands above. See some examples below.

1. Info about the partitions and nodes
List all the partitions available to you and the nodes therein:

sinfo

Nodes in state idle can accept new jobs.

Show a partition configuratuin, for example, SOE_main

scontrol show partition=SOE_main

Show current info about a specific node:

scontrol show node=<nodename>

You can also specify a group of nodes in the command above. For example, if your MPI job is running across soenode05,06,35,36, you can execute the command below to get the info on the nodes you are interested in:

scontrol show node=soenode[05-06,35-36]

An informative parameter in the output to look at would be CPULoad. It allows you to see how your application utilizes the CPUs on the running nodes.

2. Submit scripts
The header in a submit script specifies job name, partition (queue), time limit, memory allocation, number of nodes, number of cores, and files to collect standard output and error at run time, for example

#!/bin/bash

#SBATCH --job-name=OMP_run     # job name, "OMP_run"
#SBATCH --partition=SOE_main   # partition (queue)
#SBATCH -t 0-2:00              # time limit: (D-HH:MM) 
#SBATCH --mem=32000            # memory per node in MB 
#SBATCH --nodes=1              # number of nodes
#SBATCH --ntasks-per-node=16   # number of cores
#SBATCH --output=slurm.out     # file to collect standard output
#SBATCH --error=slurm.err      # file to collect standard errors

If the time limit is not specified in the submit script, SLURM will assign the default run time, 3 days. This means the job will be terminated by SLURM in 72 hrs. The maximum allowed run time is two weeks, 14-0:00.
If the memory limit is not requested, SLURM will assign the default 16 GB. The maximum allowed memory per node is 128 GB. To see how much RAM per node your job is using, you can run commands sacct or sstat to query MaxRSS for the job on the node - see examples below.
Depending on a type of application you need to run, the submit script may contain commands to create a temporary space on a computational node - see the discussion about using the file systems on the cluster.
Then it sets the environment specific to the application and starts the application on one or multiple nodes - see sbatch sample scripts in directory /usr/local/Samples on soemaster1.hpc.rutgers.edu.
You can submit your job to the cluster with sbatch command:

sbatch myscript.sh

3. Query job information
List all currently submitted jobs in running and pending states for a user:

squeue -u <username>

Command squeue can be run with format options to expose specific information, for example, when pending job #706 is scheduled to start running:

squeue -j 706 --format="%S"

START_TIME
2015-04-30T09:54:32

More info can be shown by placing additional format options, for example:

squeue -j 706 --format="%i %P %j %u %T %l %C %S"

JOBID PARTITION   NAME    USER STATE   TIMELIMIT  CPUS START_TIME
706   SOE_main  Par_job_3 mike PENDING 3-00:00:00 64   2015-04-30T09:54:32

To see when all the jobs, pending in the queue, are scheduled to start:

squeue --start 

List all running and completed jobs for a user

sqlog -u <username>

or

sqlog -j <JobID>

The following appreviations are used for the job states:

       CA   CANCELLED      Job was cancelled.

       CD   COMPLETED      Job completed normally.

       CG   COMPLETING     Job is in the process of completing.

       F    FAILED         Job termined abnormally.

       NF   NODE_FAIL      Job terminated due to node failure.

       PD   PENDING        Job is pending allocation.

       R    RUNNING        Job currently has an allocation.

       S    SUSPENDED      Job is suspended.

       TO   TIMEOUT        Job terminated upon reaching its time limit.

You can specify the fields you would like to see in the output of sqlog:

sqlog --format=list

The command below, for example, provides Job ID, user name, exit state, start date-time, and end date-time for job #2831:

sqlog -j 2831 --format=jid,user,state,start,end

List status info for a currently running job:

sstat -j <jobid>

A formatted output can be used to gain only a specific info, for example, the maximum resident RAM usage on a node:

sstat --format="JobID,MaxRSS" -j <jobid>

To get statistics on completed jobs by jobID:

sacct --format="JobID,JobName,MaxRSS,Elapsed" -j <jobid>

To view the same information for all jobs of a user:

sacct --format="JobID,JobName,MaxRSS,Elapsed" -u <username>

To print a list of fields that can be specified with the --format option:

sacct --helpformat

For example, to get Job ID, Job name, Exit state, start date-time, and end date-time for job #2831:

sacct -j 2831 --format="JobID,JobName,State,Start,End"

Another useful command to gain information about a running job is scontrol:

scontrol show job=<jobid>

4. Cancel a job
To cancel one job:

scancel <jobid>

To cancel one job and delete the TMP directory created by the submit script on a node:

sdel <jobid>

To cancel all the jobs for a user:

scancel -u <username>

To cancel one or more jobs by name:

scancel --name <myJobName>