gsAssembly (Newbler) de novo behaviour, inputs and outputs

[nicolallias]

Hello there,
It appears that the content of the ACE file is quite inconsistent with the fasta files content and the 454NewblerMetrics file:
Sometimes, the fna files are empty, 454NewblerMetrics has no contigs nor isotigs but...
The corresponding ACE will have a hundred contigs/isotigs with a mean depth of 10 000 and minimum size of 120.
Looking into the ace file show that these sequences are fulled with "*".

So I wonder: is the ace file a temporary (unfiltered) one ?

Another point: it seems that running a de novo assembly starting from fasta and not sff improve the assembly quality (less "*" in the sequences)

Anyone has seen that ? Is there some Newbler options to use for fixing this ?
Cheers

[flxlex]

Based on the fact that you state that the 454NewblerMetrics file reports no contigs, I would assume there is something that prevents assembly (or is this mapping?). Any contigs in the ace file are probably artifacts.

What kind of project/sample/reads do you have?

The '*' symbols represent gaps introduced to optimize the alignment, and 454 ace files have tons of them due to the homopolymer errors (or rather, variation in homopolymer length between reads). I would not deem the amount of these '*' a measure of quality. If you want to know the effect of using fasta input over sff, I would take reads from a known genome and check the correctness of the contigs relative to the reference sequence. Although I expect sff input to give better results, you never know...

If somebody has done this already, let me know :-)

[nicolallias]

Hi flxlex,
I'm considering de novo assemblies only, these observations are based on the study of dozens of assemblies done with Newbler 2.3 and this problem occurs:
- on gDNA from bacteria
- on gDNA from eukarya
- on cDNA (option -cdna) from plantae
But I all cases have some example cons.

Using the same raw datas we obtained different behaviour from newbler.
If we provide a sff file, contigs will be mainly composed by '*' what is not true if we basicly convert this file into fasta and assmble it with newbler. If doing so the asmmbly will look just fine.
Where could the behaviour difference could come from ?

Still investigate...

[flxlex]

Hi flxlex,
I'm considering de novo assemblies only, these observations are based on the study of dozens of assemblies done with Newbler 2.3 and this problem occurs:
- on gDNA from bacteria
- on gDNA from eukarya
- on cDNA (option -cdna) from plantae
But I all cases have some example cons.

I don't understand, you get empty fna files and ace files with many '*' contigs for all these assemblies?

Using the same raw datas we obtained different behaviour from newbler.
If we provide a sff file, contigs will be mainly composed by '*' what is not true if we basicly convert this file into fasta and assmble it with newbler. If doing so the asmmbly will look just fine.
Where could the behaviour difference could come from ?

I am not sure, but what I would be more interested in is how correct the contigs are between assemblies using sff and fasta files. if you do this for a known genome (e.g. E. coli) what do you find?

[nicolallias]

I don't understand, you get empty fna files and ace files with many '*' contigs for all these assemblies?

Yes

I am not sure, but what I would be more interested in is how correct the contigs are between assemblies using sff and fasta files. if you do this for a known genome (e.g. E. coli) what do you find?

I will do that.

Edit: Both alignments on sff and fasta have been proceeded on E.coli, both gave ace and fna files full of contigs. But I won't look after the best method (fasta or sff) for alignment : the main question here is why ?
Sometimes we have nothing (ace fulled of "*", fna files empty) with the sff while we have something (ace and fna files have contigs) when starting with a fasta ?

We're getting contact with Roche...

[nicolallias]

The problem seems to be the sff file, software developers at 454 are working on this.
Hope some good news soon ;-)

[nicolallias]

Some news : the matter seems to be located on the sff file generation...