nested fosmid ends?

Ask questions about sequence improvement / finishing D. mojavensis projects here.
Post Reply
Posts: 99
Joined: Sun Feb 04, 2007 10:19 pm
Location: Moravian College, Bethlehem PA

nested fosmid ends?

Post by cjones » Thu Mar 22, 2007 7:47 pm

Erica has almost finished her assembly, but she's got an odd issue that neither Stasy nor I can figure out:

The "ends-too-far-apart" bracket connecting the ends of the fosmid (in purple) simply reflects primer pairs from the fosmid ends which consed thinks belong to a subclone, and believes are therefore too far apart. No problem, we all have those. What we can't figure out is the source for the yellow brackets, as their "ends" are between the fosmid ends. Each reflects a single chunk of DNA, eg. 39808080.b1 and 39808080.g1.

Erica says she didn't swap reads with anyone (which wouldn't solve the problem here anyway), but these reads don't appear to be in her first .ace file, so we're not sure where they came from. Stripping out the offending reads seems like cheating, but we're not sure how to progress from here. Any suggestions?
Chris Jones
Assoc. Prof. of Biology
Moravian College
Bethlehem PA

Posts: 211
Joined: Sun Feb 04, 2007 10:29 pm
Location: Washington University in St Louis

fosmid ends

Post by cshaffer » Fri Mar 23, 2007 8:43 pm

Are you sure they are not in the original ace file? You can open the ace.1 file and enter in the number into the "find reads containing (*'s allowed)" box. If the read is in the assembly you should be able to find it and if double click on its name in the above box consed will open an aligned reads window and scroll to the location of that read.

It is also that the traces were in the chromat_dir but the reads might not have been included in the first assembly by phrap. It is possible after adding oligo reads that there was now sufficient data to assembly these reads so they only appear in later ace files.

It is also possible they were assembled in the origial ace file but just not highlighted by assembly view. Assembly view can make mistakes like that especially when there are gaps. It might only have started highlighting these reads once you got to a single contig.

As long as they are incorporated in the correct orientation I would not be worried about these; we know that there are fosmid reads in with the other reads but there is just not an easy way to tell consed about these so this is where computers fail and human brains are used to know that this is not really a concern even if the computer says it is.

Post Reply