454IsotigsLayout.txt - contigs don't match to any isotig?

[dschika]

Hey everybody,

In the IsotigsLayout file I found following:

PHP Code:

>isogroup00514  numIsotigs=1  numContigs=4
   Length : 1060  677   177   71    (bp)
   Contig : 10265 03234 12018 15110 Total:
isotig02514 >>>>>            >>>>>  1131         

>isogroup00515  numIsotigs=1  numContigs=4
   Length : 129   1     23    524   (bp)
   Contig : 11894 15180 08389 02141 Total:
isotig02515 >>>>>       <<<<< >>>>>   676

>isogroup00516 


Why are there 4 contigs listed in isogroup 514, but just two are in an isotig? Looking in the Isotig.fna I found >isotig02514 followed by >contig03234. So I expected >contig12018 to be next, but the next entry was the next isotig from isogroup00515. And as you can see contig15180 also doesn't match the isotig. Any hints?

cheers,
Thomas

[westerman]

In a recent project I found that a lot of the problematic contigs were from virus contamination. The reads were split up in multiple ways that created strange contigs that did not get placed within the isotigs. Re-running the assembly with the '-rip' option in order to keep the reads from (mostly) being ripped apart help out the overall project.

In your particular case looking in the 454AllContigs.fna file to see what contig12018 looks like might give you a clue as to if the contig is any good to begin with.

[Jeremy]

Hi
I just checked my data and I also see contigs that are listed but not used in isotigs. For you'r isogroup515 contig 15180 is not used because it is one of those stupid contigs made up of 1-5 bases.

here is an example I checked in my data

>isogroup00051  numIsotigs=4  numContigs=10
   Length : 417   294   502   2     2     157   20    1001  211   300   (bp)
   Contig : 15069 10938 12303 16373 00297 16372 00298 09511 15400 15401 Total:
isotig00531 >>>>>                         >>>>> >>>>> <<<<< >>>>> >>>>>  2108
isotig00532 >>>>>                   >>>>>       >>>>> <<<<< >>>>> >>>>>  1953
isotig00533 >>>>>                                     <<<<< >>>>> >>>>>  1930
isotig00534       >>>>>                                     >>>>> >>>>>   805

I checked contig12303 from my above example and noticed that it joins to contig15400 but only has a read depth of 4. Here is a grep from 454ContigGraph.txt (\t = tab)

[1] "15400\tcontig15400\t211\t74.8"                             
[2] "C\t9511\t5'\t15400\t5'\t33"                                  
[3] "C\t15400\t3'\t12303\t5'\t4"                                  
[4] "C\t10938\t3'\t15400\t5'\t23"                                 
[5] "C\t15401\t5'\t15400\t3'\t78"                                 
[6] "S\t531\t2108\t15069:+;16372:+;298:+;9511:-;15400:+;15401:+"
[7] "S\t532\t1953\t15069:+;297:+;298:+;9511:-;15400:+;15401:+"  
[8] "S\t533\t1930\t15069:+;9511:-;15400:+;15401:+"              
[9] "S\t534\t805\t10938:+;15400:+;15401:+"

it may have something to do with an insufficient read depth making the program think that this contig is an artefact.

[dschika]

Thanks for your replies!
I checked the seqs in the AllContigs file and I have seen that the contigs without >>>>> are marked as cyclyc or thresh. Using the -rip optin ends up with less contigs per isotig (max. 4). Don't I miss a lot of information? Or is the assembly even getting more reliable (which is what I think), as the contigs are not split? (I searched for that parameter a long time, but missed it somehow )

I had again a deeper look in the 454ContigGraph and I think it's not a read depth problem.
The contigs which don't have >>>>> in the IsotigLayout.txt aren't member of any scaffold (lines beginning with S in ContigGraph). But in the C lines there is a connection to another contig of the isotig, i.e.

C	15110	5'	3234	5'	9    => Edge between contig15110 and contig03234 found
S	2514	1131	10265:+;15110:+   => Scaffold with contigs 10265 and 15110 -> isotig02514

I GUESS (!) it could be a bug in the generation of the Layout file.

But this still doesn't explain why contig03234 is in the Isotig.fna and contig12018 is not and both are cyclyc.

[Jeremy]

what are the read depths of all the other edges to contig 15110? My guess is they will be significantly higher than 9 (similar to the case in my example above).

[dschika]

here is the grep result:

> grep 15110 454ContigGraph.txt 
15110	contig15110	71	8.0
C	15110	5'	3234	5'	9
C	15110	5'	10265	3'	3
S	2514	1131	10265:+;15110:+
I	15110	CCCCACCCTTCTTGGGACCCTTCTTGCTCTTCTTTTtCCCTTTtGCTATCAATGCCACATCCTCCTCATCC

[Jeremy]

yeah I guess it was just a coincidence that contig12303 had a low read depth in the example above as it is listed as edge_thresh, although the only edge that is has listed is to contig15110

[westerman]

Re: Using the '-rip' option versus not using the option.

In my one comparative test so far -- this was on 454 run with multiple projects within it; all of which seemed to be contaminated and for which the 454 software created strange contigs -- the '-rip' option produced roughly the same percentage of assembled bases. Some projects seeing a bit more assembled reads and some less but all within 1%. The '-rip' option also produced slightly more large contigs. The number of contigs not used in the isotigs dropped dramatically. The handful of contigs that were not used in the isotigs are 'threshold' contigs.

So, in summary at least for this project, the '-rip' option is a good choice.

I may go back to some of my older and less contaminated projects to see what would happen when using the '-rip' option.

I would be interested in other people's opinion of using the '-rip' option.

[dschika]

My observations using -rip option are:
- less aligned reads, but not considerably less
- less aligned bases, roughly between 1% and 3%
- drop in the average number of contigs per isotig
- the number of contigs not in isotigs drops a bit. BUT: the overall number of contigs in 454AllContigs.fna drops considerably (e.g. from 16000 to 14000 or 66000 to 52000)
- nearly all of the contigs not used are 'threshold'-contigs (I found 3 (out of 210 not used contigs) which had the status=none). Only 1 'threshold'-contig was used in an isotig.
- more large contigs are produced.

I think I will use the -rip option for my assemblies. But I would also be interested in other people's experiences/opinons...I start a new thread for that!


Cheers,
Thomas

[pmiguel]

Originally Posted by westerman

In my one comparative test so far -- this was on 454 run with multiple projects within it; all of which seemed to be contaminated and for which the 454 software created strange contigs

BTW, there was viral sequence in this project. But there is no particular reason to suspect "contamination", per se. Contamination might be a term to use if one suspected that RNA from a viral prep had spilled into a tissue RNA prep. However if, as seems more likely, the tissue in question was expressing viral transcripts, then "contamination" is not the right word to use.

--
Phillip