Bastien
Chevreux
bach@chevreux.org

> Solomon Short

> Expect the worst. You'll never get disappointed.

# Assembly of EST/RNASeq data with MIRA3

## Introduction

This document is not complete yet and some sections may be a bit unclear. I'd be happy to receive suggestions for improvements.

### Some reading requirements

This guide assumes that you have basic working knowledge of Unix systems, know the basic principles of sequencing (and sequence assembly) and what assemblers do.

Basic knowledge on mRNA transcription and EST sequences should also be present.

While there are step by step walkthroughs on how to setup your EST data and then perform assemblies regarding different requirements, this guide expects you to read at some point in time

- the mira_usage introductory help file so that you have a basic knowledge on how to set up projects in mira for Sanger sequencing projects.

- the mira_454 introductory help file so that you have a basic knowledge on how to set up projects in mira for 454 sequencing projects.

- and last but not least the mira_reference help file to look up some command line options.

## Preliminaries: on the difficulties of assembling ESTs

Assembling ESTs can be, from an assemblers point of view, pure horror. E.g., it may be that some genes have thousands of transcripts while other genes have just one single transcript in the sequenced data. Furthermore, the presence of 5' and 3' UTR, transcription variants, splice variants, homologues, SNPs etc.pp complicates the assembly in some rather interesting ways.

### Poly-A tails in EST data

Poly-A tails are part of the mRNA and therefore also part of sequenced data. They can occur as poly-A or poly-T, depending from which direction and which part of the mRNA was sequenced. Having poly-A/T tails in the data is a something of a double edged sword. More specifically., if the 3' poly-A tail is kept unmasked in the data, transcripts having this tail will very probably not align with similar transcripts from different splice variants (which is basically good). On the other hand, homopolymers (multiple consecutive bases of the same type) like poly-As are features that are pretty difficult to get correct with today's sequencing technologies, be it Sanger, Solexa or, with even more problems problems, 454. So slight errors in the poly-A tail could lead to wrongly assigned splice sites ... and wrongly split contigs.

This is the reason why many people cut off the poly-A tails. Which in turn may lead to transcripts from different splice variants being assembled together.

Either way, it's not pretty.

### Lowly expressed transcripts

Single transcripts (or very lowly expressed transcripts) containing SNPs, splice variants or similar differences to other, more highly expressed transcripts are a problem: it's basically impossible for an assembler to distinguish them from reads containing junky data (e.g. read with a high error rate or chimeras). The standard setting of many EST assemblers and clusterers is therefore to remove these reads from the assembly set. MIRA handles things a bit differently: depending on the settings, single transcripts with sufficiently large differences are either treated as debris or can be saved as singlet.

### Chimeras

Chimeras are sequences containing adjacent base stretches which are not occurring in an organism as sequenced, neither as DNA nor as (m)RNA. Chimeras can be created through recombination effects during library construction or sequencing. Chimeras can, and often do, lead to misassemblies of sequence stretches into one contig although they do not belong together. Have a look at the following example where two stretches (denoted by `x` and `o` are joined by a chimeric read r4 containing both stretches:

    r1 xxxxxxxxxxxxxxxx
    r2 xxxxxxxxxxxxxxxxx
    r3 xxxxxxxxxxxxxxxxx
    r4 xxxxxxxxxxxxxxxxxxx|oooooooooooooo
    r5                        ooooooooooo
    r6                        ooooooooooo
    r7                          ooooooooo

The site of the recombination event is denoted by `x|o` in read r4.

MIRA does have a chimera detection -- which works very well in genome assemblies due to high enough coverage -- by searching for sequence stretches which are not covered by overlaps. In the above example, the chimera detection routine will almost certainly flag read r4 as chimera and only use a part of it: either the `x` or `o` part, depending on which part is longer. There is always a chance that r4 is a valid read though, but that's a risk to take.

Now, that strategy would also work totally fine in EST projects if one would not have to account for lowly expressed genes. Imagine the following situation:

    s1 xxxxxxxxxxxxxxxxx
    s2         xxxxxxxxxxxxxxxxxxxxxxxxx
    s3                          xxxxxxxxxxxxxxx

Look at read s2; from an overlap coverage perspective, s2 could also very well be a chimera, leading to a break of an otherwise perfectly valid contig if s2 were cut back accordingly. This is why chimera detection is switched off by default in MIRA.

When starting an EST assembly via the `--job=est,...` switch, chimera detection is switched off by default. It is absolutely possible to switch on the SKIM chimera detection afterwards via -CL:ascdc. However, this will have exactly the effects described above: chimeras in higher coverage contigs will be detected, but perfectly valid low coverage contigs will be torn apart.

It is up to you to decide what you want or need.

### Missing library normalisation: very highly expressed transcripts

Another interesting problem for de-novo assemblers are non-normalised EST libraries. In each cell, the number of mRNA copies per gene may differ by several orders of magnitude, from a single transcripts to several tens of thousands. Pre-sequencing normalisation is a wet-lab procedure to approximately equalise those copy numbers. This can however, introduce other artifacts.

If an assembler is fed with non-normalised EST data, it may very well be that an overwhelming number of the reads comes only from a few genes (house-keeping genes). In Sanger sequencing projects this could mean a couple of thousand reads per gene. In 454 sequencing projects, this can mean several tens of thousands of reads per genes. With Solexa data, this number can grow to something close to a million.

Several effects then hit a de-novo assembler, the three most annoying being (in ascending order of annoyance): a) non-random sequencing errors then look like valid SNPs, b) sequencing and library construction artefacts start to look like valid sequences if the data set was not cleaned "enough" and more importantly, c) an explosion in time and memory requirements when attempting to deliver a "good" assembly. A sure sign of the latter are messages from MIRA about megahubs in the data set.

The guide on how to tackle hard projects with MIRA gives an overview on how to hunt down sequences which can lead to the assembler getting confused, be it sequencing artefacts or highly expressed genes.

## Preprocessing of ESTs

With contributions from Katrina Dlugosch

EST sequences necessarily contain fragments of vectors or primers used to create cDNA libraries from RNA, and may additionally contain primer and adaptor sequences used during amplification-based library normalisation and/or high-throughput sequencing. These contaminant sequences need to be removed prior to assembly. MIRA can trim sequences by taking contaminant location information from a SSAHA2 or SMALT search output, or users can remove contaminants beforehand by trimming sequences themselves or masking unwanted bases with lowercase or other characters (e.g. 'x', as with `cross_match`). Many folks use preprocessing trimming/masking pipelines because it can be very important to try a variety of settings to verify that you've removed all of your contaminants (and fragments thereof) before sending them into an assembly program like MIRA. It can also be good to spend some time seeing what contaminants are in your data, so that you get to know what quality issues are present and how pervasive.

Two features of next generation sequencing can introduce errors into contaminant sequences that make them particularly difficult to remove, arguing for preprocessing: First, most next-generation sequence platforms seem to be sensitive to excess primers present during library preparation, and can produce a small percentage of sequences composed entirely of concatenated primer fragments. These are among the most difficult contaminants to remove, and the program TagDust () was recently developed specifically to address this problem. Second, 454 EST data sets can show high variability within primer sequences designed to anchor to polyA tails during cDNA synthesis, because 454 has trouble calling the length of the necessary A and T nucleotide repeats with accuracy.

A variety of programs exist for preprocessing. Popular ones include cross_match () for primer masking, and SeqClean (), Lucy (), and SeqTrim () for both primer and polyA/T trimming. The pipeline SnoWhite () combines Seqclean and TagDust with custom scripts for aggressive sequence and polyA/T trimming (and is tolerant of data already masked using cross_match). In all cases, the user must provide contaminant sequence information and adjust settings for how sensitive the programs should be to possible matches. To find the best settings, it is helpful to look directly at some of the sequences that are being trimmed and inspect them for remaining primer and/or polyA/T fragments after cleaning.

When using `mira` or `miraSearchESTSNPs` with the the simplest parameter calls (using the "--job=..." quick switches), the default settings used include pretty heavy sequence pre-processing to cope with noisy data. Especially if you have your own pre-processing pipeline, you must then switch off different clip algorithms that you might have applied previously yourself. Especially poly-A clips should never be run twice (by your pipeline and by `mira`) as they invariably lead to too many bases being cut away in some sequences,

Here too: In some cases MIRA can get confused if something with the pre-processing went wrong because, e.g., unexpected sequencing artefacts like unknown sequencing vectors or adaptors remain in data. The guide on how to tackle hard projects with MIRA gives an overview on how to hunt down sequences which can lead to the assembler getting confused, be it sequencing artefacts or highly expressed genes.

## The difference between assembly and clustering

MIRA in its base settings is an assembler and not a clusterer, although it can be configured as such. As assembler, it will split up read groups into different contigs if it thinks there is enough evidence that they come from different RNA transcripts.

### Splitting transcripts into contigs based on SNPs

Imagine this simple case: a gene has two slightly different alleles and you've sequenced this:

    A1-1  ...........T...........
    A1-2  ...........T...........
    A1-3  ...........T...........
    A1-4  ...........T...........
    A1-5  ...........T...........
    B2-1  ...........G...........
    B2-2  ...........G...........
    B2-3  ...........G...........
    B2-4  ...........G...........

Depending on base qualities and settings used during the assembly like, e.g., -CO:mr:mrpg:mnq:mgqrt:emea:amgb MIRA will recognise that there's enough evidence for a T and also enough evidence for a G at that position and create two contigs, one containing the "T" allele, one the "G". The consensus will be >99% identical, but not 100%.

Things become complicated if one has to account for errors in sequencing. Imagine you sequenced the following case:

    A1-1  ...........T...........
    A1-2  ...........T...........
    A1-3  ...........T...........
    A1-4  ...........T...........
    A1-5  ...........T...........
    B2-1  ...........G...........

It shows very much the same like the one from above, except that there's only one read with a "G" instead of 4 reads. MIRA will, when using standard settings, treat this as erroneous base and leave all these reads in a contig. It will likewise also not mark it as SNP in the results. However, this could also very well be a lowly expressed transcript with a single base mutation. It's virtually impossible to tell which of the possibilities is right.

You can of course force MIRA to mark situations like the one depicted above by, e.g., changing the parameters for -CO:mrpg:mnq:mgqrt. But this may have the side-effect that sequencing errors get an increased chance of getting flagged as SNP.

Further complications arise when SNPs and potential sequencing errors meet at the same place. consider the following case:

    A1-1  ...........T...........
    A1-2  ...........T...........
    A1-3  ...........T...........
    A1-4  ...........T...........
    B1-5  ...........T...........
    B2-1  ...........G...........
    B2-2  ...........G...........
    B2-3  ...........G...........
    B2-4  ...........G...........
    E1-1  ...........A...........

This example is exactly like the first one, except an additional read `E1-1` has made it's appearance and has an "A" instead of a "G" or "T". Again it is impossible to tell whether this is a sequencing error or a real SNP. MIRA handles these cases in the following way: it will recognise two valid read groups (one having a "T", the other a "G") and, in assembly mode, split these two groups into different contigs. It will also play safe and define that the single read `E1-1` will not be attributed to either one of the contigs but, if it cannot be assembled to other reads, form an own contig ... if need to be even only as single read (a singlet).

Depending on some settings, singlets may either appear in the regular results or end up in the debris file.

### Splitting transcripts into contigs based on larger gaps

Gaps in alignments of transcripts are handled very cautiously by MIRA. The standard settings will lead to the creation of different contigs if three or more consecutive gaps are introduced in an alignment. Consider the following example:

    A1-1  ..........CGA..........
    A1-2  ..........*GA..........
    A1-3  ..........**A..........
    B2-1  ..........***..........
    B2-2  ..........***..........

Under normal circumstances, MIRA will use the reads `A1-1`, `A1-2` and `A1-3` to form one contig and put `B2-1` and `B2-2` into a separate contig. MIRA would do this also if there were only one of the B2 reads.

The reason behind this is that the probability for having gaps of three or more bases only due to sequencing errors is pretty low. MIRA will therefore treat reads with such attributes as coming from different transcripts and not assemble them together, though this can be changed using the -AL:egp:egpl parameters of MIRA if wanted.

#### Problems with homopolymers, especially in 454 sequencing

As 454 sequencing has a general problem with homopolymers, this rule of MIRA will sometimes lead formation of more contigs than expected due to sequencing errors at "long" homopolymer sites ... where long starts at ~7 bases. Though MIRA does know about the problem in 454 homopolymers and has some routines which try to mitigate the problem. this is not always successful.

## mira and miraSearchESTSNPs

The assembly of ESTS can be done in two ways when using the MIRA3 system: by using mira or miraSearchESTSNPs.

If one has data from only one strain, mira using the "--job=est" quickmode switch is probably the way to go as it's easier to handle.

For data from multiple strains where one wants to search SNPs, miraSearchESTSNPs is the tool of choice. It's an automated pipeline that is able to assemble transcripts cleanly according to given organism strains. Afterwards, an integrated SNP analysis highlights the exact nature of mutations within the transcripts of different strains.

### Using mira for EST assembly

Using mira in EST projects is quite useful to get a first impression of a given data set or when used in projects that have no strain or only one strain.

It is recommended to use 'est' in the -job= quick switch to get a good initial settings default and then eventually adapt with own settings.

Note that by their nature, single transcripts end up in the debris file as they do not match any other reads and therefore cannot be aligned.

An interesting approach to find differences in multiploid genes is to use the result of an "mira --job=est ..." assembly as input for the third step of the miraSearchESTSNPs pipeline.

### Using mira for EST clustering

Like for EST assembly, it is recommended to use 'est' in the -job= quick switch to get a good initial settings default. Then however, one should adapt a couple of switches to get a clustering like alignment:

`-AL:egp=no`

  switching off extra gap penalty in alignments allows assembly of transcripts having gap differences of more than 3 bases

`-AL:egpl=...`

  In case -AL:egp is not switched off, the extra gap penalty level can be fine tuned here.

`-AL:megpp=...`

  In case -AL:egp is not switched off, the maximum extra gap penalty in percentage can be fine tuned here. This allows, together with -AL:egpl (see below), to have MIRA accept alignments which are two or three bases longer than the 3 bases rejection criterion of the standard -AL:egpl=split_on_codongaps in EST assemblies.

`-CO:asir=yes`

  This forces MIRA to assume that valid base differences (occurring in several reads) in alignments are SNPs and not repeats/marker bases for different variants. Note that depending on whether you have only one or several strains in your assembly, you might want to enable or disable this feature to allow/disallow clustering of reads from different strains.

`-CO:mrpg:mnq:mgqrt`

  With these three parameters you can adjust the sensitivity of the repeat / SNP discovery algorithm.

`-AL:mrs=...`

  When -CO:asir=no and -AL:egp=no, MIRA has lost two of its most potent tools to not align complete nonsense. In those cases, you should increase the minimum relative score allowed in Smith-Waterman alignments to levels which are higher than the usual MIRA standards. 90 or 95 might be a good start for testing.

`-CO:rodirs=...`

  Like -AL:mrs above, -CO:rodirs is a fallback mechanism to disallow building of completely nonsensical contigs when -CO:asir=no and -AL:egp=no. You should decrease -CO:rodirs to anywhere between 10 and 0.

Please look up the complete description of the above mentioned parameters in the MIRA reference manual, they're listed here just with the why one should change them for a clustering assembly.

Remember that some of the parameters above can be set independently for reads of different sequencing technologies. E.g., when assembling EST sequences from Sanger and 454 sequencing technologies, it is absolutely possible to allow the 454 sequences from having large gaps in alignments (to circumvent the homopolymer problem), but to disallow Sanger sequences from having them. The parameters would need be set like this:

    $ mira [...] --job=est,... [...]
      SANGER_SETTINGS -AL:egp=yes:egpl=split_on_codongaps
      454_SETTINGS -AL:egp=no

or in shorter form (as `--job=est` already presets `-AL:egp=yes:egpl=split_on_codongaps` for all technologies):

    $ mira [...] --job=est,... [...]
      454_SETTINGS -AL:egp=no

### Using miraSearchESTSNPs for EST assembly

miraSearchESTSNPs is a pipeline that reconstructs the pristine mRNA transcript sequences gathered in EST sequencing projects of more than one strain, which can be a reliable basis for subsequent analysis steps like clustering or exon analysis. This means that even genes that contain only one transcribed SNP on different alleles are first treated as different transcripts. The optional last step of the assembly process can be configured as a simple clusterer that can assemble transcripts containing the same exon sequence -- but only differ in SNP positions -- into one consensus sequence. Such SNPs can then be analysed, classified and reliably assigned to their corresponding mRNA transcriptome sequence. However, it is important to note that miraSearchESTSNPs is an assembler and not a full blown clustering tool.

Generally speaking, miraSearchESTSNPs is a three-stage assembly system that was designed to catch SNPs in different strains and reconstruct the mRNA present in those strains. That is, one really should have different strains to analyse (and the information provided to the assembler) to make the most out of miraSearchESTSNPs. Here is a quick overview on what miraSearchESTSNPs does:

1. Step 1: assemble everything together, not caring about strain information. Potential SNPs are not treated as SNPs, but as possible repeat marker bases and are tagged as such (temporarily) to catch each and every possible sequence alignment which might be important later. As a result of this stage, the following information is written out:

   1. Into `step1_snpsinSTRAIN_<strainname>.caf` all the sequences of a given strain that are in contigs (can be aligned with at least one other sequence) - also, all sequences that are singlets BUT have been tagged previously as containing tagged bases showing that they aligned previously (even to other strains) but were torn apart due to the SNP bases.

   2. Into `step1_nosnps_remain.caf` all the remaining singlets.

   Obviously, if one did not provide strain information to the assembly of step 1, all the sequences belong to the same strain (named "default"). The CAF files generated in this step are the input sequences for the next step.

   If you want to apply clippings to your data (poly-A/T or reading clipping information from SSAHA2 or SMALT), then do this only in step 1! Do not try to re-appply them in step 2 or 3 (or only if you think you have very good reasons to do so. Once loaded and/or applied in step 1, the clipping information is carried on by MIRA to steps 2 and 3.

2. Step 2: Now, miraSearchESTSNPs assembles each strain independently from each other. Again, sequences containing SNPs are torn apart into different contigs (or singlets) to give a clean representation of the "really sequenced" ESTs. In the end, each of the contigs (or singlets) coming out of the assemblies for the strains is a representation of the mRNA that was floating around the given cell/strain/organism. The results of this step are written out into one big file (`step2_reads.caf`) and a new straindata file that goes along with those results (`step2_straindata.txt`).

3. Step 3: miraSearchESTSNPs takes the result of the previous step (which should now be clean transcripts) and assembles them together, this time allowing transcripts from different strains with different SNP bases to be assembled together. The result is then written to `step3_out.*` files and directories.

miraSearchESTSNPs can also be used for EST data of a single strain or when no strain information is available. In this case, it will cleanly sort out transcripts of almost identical genes or, when eukaryotic ESTs are assembled, according to their respective allele when these contain mutations.

Like the normal mira, miraSearchESTSNPs keeps track on a lot of things and writes out quite a lot of additional information files after each step. Results and and additional information of step 1 are stored in `step1_*` directories. Results and information of step 2 are in `<strainname>_*` directories. For step 3, it's `step3_*` again.

Each step of miraSearchESTSNPs can be configured exactly like mira via command line parameters.

The pipeline of miraSearchESTSNPs is almost as flexible as mira itself: if the defaults set by the quick switches are not right for your use case, you can change about any parameter you wish via the command line. There are only two things which you need to pay attention to

1. a straindata file must be present for step 1 (`*_straindata_in.txt`), but it can very well be an empty file.

2. the naming of the result files is fixed (for all three steps), you cannot change it.

## Walkthroughs

These walkthroughs use "msd" as project name (acronym for My Simple Dataset), please replace that with your own project name according to the MIRA naming convention.

### mira with "--job=est"

#### Example: One strain, Sanger without vectors and no XML

Given is just a FASTA and FASTA quality file, where the Sanger sequencing vector sequences and problematic things (like bad quality) have been either completely removed from the data or were masked with "X". Apart from that, no further processing (poly-A removal etc.) was done. Your directory looks like this:

    bach@arcadia:$ ls -l
    -rwxr--r-- 1 bach bach 15486163 2009-02-22 21:01 msd_in.sanger.fasta
    -rwxr--r-- 1 bach bach 38017687 2009-02-22 21:01 msd_in.sanger.fasta.qual

Then, use this command:

    $ mira --project=msd
      --job=denovo,est,accurate,sanger
      SANGER_SETTINGS
      -CL:qc=no
      >& log_assembly.txt

We switch off the Sanger quality clips because bad quality is already trimmed away by your pipeline.

#### Example: One strain, 454 with XML ancillary data

Like above, but this time 454 sequencing and the FASTA files contain everything (including remaining adaptors and bad quality), but there's a XML with ancillary data which contains all necessary clips (like generated by, e.g., `sff_extract`):

    bach@arcadia:$ ls -l
    -rwxr--r-- 1 bach bach 15486163 2009-02-22 21:01 msd_in.454.fasta
    -rwxr--r-- 1 bach bach 38017687 2009-02-22 21:01 msd_in.454.fasta.qual
    -rwxr--r-- 1 bach bach 10433244 2009-02-22 21:01 msd_traceinfo_in.454.xml

Then, use this command:

    bach@arcadia:$  mira --project=msd
      --job=denovo,est,accurate,454
      454_SETTINGS
      -CL:qc=no
      >& log_assembly.txt

We just switch off our quality clip for 454 (and load the quality clips from the XML), poly-A removal is performed by MIRA. Loading of TRACEINFO XML data must not be switched on as it's the default for 454 data.

#### Example: One strain, 454 with XML ancillary data, poly-A already removed.

Like above, but this time the data was pre-processed by another program to mask the poly-A stretches with X:

    bach@arcadia:$ ls -l
    -rwxr--r-- 1 bach bach 15486163 2009-02-22 21:01 msd_in.454.fasta
    -rwxr--r-- 1 bach bach 38017687 2009-02-22 21:01 msd_in.454.fasta.qual
    -rwxr--r-- 1 bach bach 10433244 2009-02-22 21:01 msd_traceinfo_in.454.xml

Then, use this command:

    bach@arcadia:$ mira --project=msd
      --job=denovo,est,accurate,454
      454_SETTINGS
      -CL:qc=no:cpat=no
      >& log_assembly.txt

We just switch off our quality clip (and load the quality clips from the XML) and also switch off poly-A clipping. Remember, never perform poly-A/T clipping twice on a data set.

#### Example: Two strains, 454 with XML ancillary data, poly-A already removed.

Like above, but this time we assign reads to different strains. This can happen either by putting the strain information into the XML file (using the `strain` field of the NCBI TRACEINFO format definition) or by using a two column, tab-delimited file which mira loads on request.

As written. when using XML no change to the command line from the last example would be needed. This example uses the extra file with strain information. The file `msd_straindata_in.txt` contains key value pair information on the relationship of reads to strains and looks like this (gnlti* are name of reads):

    bach@arcadia:$ cat msd_straindata_in.454.txt
    gnlti136478626 tom
    gnlti136479357 tom
    gnlti136479063 tom
    gnlti136478624 jerry
    gnlti136479522 jerry
    gnlti136477918 jerry

Then, use this command (note the additional -LR:lsd option):

    bach@arcadia:$ mira --project=msd
      --job=denovo,est,accurate,454
      454_SETTINGS
      -LR:lsd=yes
      -CL:qc=no:cpat=no
      >& log_assembly.txt

### miraSearchESTSNPs

#### Example: Two strains, Sanger with masked sequences, no XML

Given just a FASTA and FASTA quality file, where the Sanger sequencing vectors and all sequencing related things (like bad quality) have been either completely removed from the data or were masked with "X". Apart from that, no further processing (poly-A removal etc.) was done.

You have n strains (in this example n=2) called "tom" and "jerry"

Your directory looks like this:

    bach@arcadia:$ ls -l
    -rw-r--r-- 1 bach bach  5276 2009-02-22 21:23 msd_in.sanger.fasta
    -rw-r--r-- 1 bach bach 13827 2009-02-22 21:23 msd_in.sanger.fasta.qual
    -rw-r--r-- 1 bach bach   120 2009-02-22 21:27 msd_straindata_in.txt

The file `msd_straindata_in.txt` contains key value pair information on the relationship of reads to strains and looks like this (gnlti* are name of reads):

    bach@arcadia:$ cat msd_straindata_in.txt
    gnlti136478626 tom
    gnlti136479357 tom
    gnlti136479063 tom
    gnlti136478624 jerry
    gnlti136479522 jerry
    gnlti136477918 jerry

To assemble, use this:

    bach@arcadia:$ miraSearchESTSNPs
      --project=msd
      --job=denovo,accurate,sanger,esps1
      >&log_assembly_esps1.txt

Note that the results of this first step are in sub-directories prefixed with "step1".

When the first step finished, continue with this (note that no "--project" is given here):

    bach@arcadia:$ miraSearchESTSNPs
      --job=denovo,accurate,esps2
      >&log_assembly_esps2.txt

Note that the results of this second step are in sub-directories prefixed with "tom", "jerry" and "remain". You will find in each directory the clean transcripts from every strain/organism.

To see which SNPs exist between both "tom" and "jerry", launch the third step:

    bach@arcadia:$ miraSearchESTSNPs
      --job=denovo,accurate,esps3
      >&log_assembly_esps3.txt

Note that the results of this third step are in sub-directories prefixed with "step3".

In the `step3_d_results` directory for example, you can transform the CAF file into a gap4 database and then look at the SNPs searching for the tags SROr, SIOr and SAOr.

## Solving common problems of EST assemblies

... continue here ...

Megahubs => track down reason (high expr, seqvec or adaptor: see mira_hard) and eliminate it