trimming issue

[malatorr]

Hi, I'm using gsAssembler 2.3 to assembly 450.000 reads. I have the xml autoTrimming variable set to false, but I can not bypass the trimming/screening step and the assembly is still using only 100.000 reads...why does this happen? Am I missing something?

Also I'm not giving any fasta by setting the screeningDatabase variable.

It seems like Newbler uses its own trimming database...is this true? how can I make gsassembler to use ALL reads i.e. whithout a screening process (at least more reads).

I believe the gsassembler 2.0 trims off less reads, 2.3 version only uses ~ 1/5 of all reads.

Thanks!

[flxlex]

What do you mean with "the assembly is still using only 100.000 reads"? In the 454NewblerMetrics file, what are the numbers for (partially) assembled, repeat, too-short reads? This might tell you where the other reads are (for example, they might very similar to each other and end up in the 'repeat' class).

[malatorr]

For example... the Metrics numbers for a 10Mb assembly project
numberOfReads = 56588, 15261;
numberOfBases = 10202379, 2403528;

newbler use only 15261 reads so there are 41327 reads lost!
The 454ReadStatus.txt file only inform about what happens with the 15261 reads.

When I look at the 454TrimStatus.txt I found this kind of lines:

Accno Trimpoints Used Used Trimmed Length Orig Trimpoints Orig Trimmed Length Raw Length
FZVIICB01EMTRK 43-48 6 1-48 48 48
FZVIICB01DAKCG 11-176 166 1-176 176 176
FZVIICB01EQFCM 220-220 1 1-220 220 220
FZVIICB01EFNF6 89-94 6 1-94 94 94
FZVIICB01AN9HI 208-208 1 1-208 208 208
FZVIICB01D4ECO 35-35 1 1-213 213 213
FZVIICB01BLVB1 26-26 1 1-76 76 76
FZVIICB01BEMNW 209-209 1 1-209 209 209
FZVIICB01DOI6O 81-83 3 1-83 83 83
FZVIICB01DS302 27-27 1 1-222 222 222
FZVIICB01EH0OY 74-79 6 1-79 79 79
FZVIICB01BE2B7 156-156 1 1-156 156 15

I found a lot of 'large' reads that has been trimmed but I'm not giving any fasta by setting the screeningDatabase variable.

The 'minimumReadLength' is 20pb so, I think that the 41327 reads became too short after the Trimming process but... why? or there exist another explanation?

When I use the 2.0 version of the Assembler and the same set of reads, the metrics shows that all the reads were used and the trimming shows the cut of only ~12pb on each sequence. It's an strange difference between 2.0 and 2.3 version.
(and the final number of contigs obtained in 2.3 is the half of the contigs obtained in 2.0 using the same parameters).

Thanks in advance!

[flxlex]

I have no explanation why 2.0 would behave so very different on your data set than 2.3. I think you should contact Roche/454 about this (they are usually very helpful).