Re: [wgs-assembler-users] consensus error

[Walenz, B. <bw...@jc...>]

[catching up on email]

The partitioned store allows multiple processes to write at the same time.  In the store, v001 (for example) has three files per consensus process.  Each set of files is a mini-store, and so each consensus process can modify it without needing locking or other fancy database operations.  When we get to scaffolding, there is only one process, so the store transparently merges all those mini-stores into one monolithic store.  The catch here is that the two formats can co-exist.  If some process works with the monolithic store, the consensus processes — operating on mini-stores — don’t ever see the change.

I’m at a loss to explain why v5 didn’t work and v2 did.  The store is easy to break like this if one isn’t careful with the editing operations.  It’s usually also easy to un-break — by removing the files that contain the monolithic store, or as an extreme, removing the whole version and recomputing it.

b


On 5/23/13 10:34 AM, "Ben Elsworth" <el...@gm...> wrote:

Hi Brian,

Thanks for the reply. I followed your advice, although I added the final unitig to version 2 not 5 as that didn't seem to work, and that has got things working. I'm not entirely sure what the difference is between the partitioned and non-partitioned formats though, and why is it working with v2 and not v5?

Regards,

Ben

On 22 May 2013 18:51, Walenz, Brian <bw...@jc...> wrote:
Hi, Ben-

I’ve seen something similar to this before.  As I recall, the store is getting confused between the partitioned (-up 3) and non-partitioned formats.  Try adding the final unitig to unpartiitoned version 5:

tigStore –g *gkpStore –t *tigStore 2 –up 3 –d layout –u 8049 > unitig8049.withcns
tigStore –g *gkpStore –t *tigStore 5 –R unitig8049.withcns

The first retrieves the output of utgcns (check that it has consensus sequence at the top, and that there is exactly one UTG line at the end) and the second adds this to version 5 (the input to cgw).

I think that what happened is that you added unitig8049 without consensus to the unpartitioned store, (the middle command, without ‘–up3’) and that is masking the untiig that is stored in partition 3. You can hopefully test this hypothesis by removing ‘-up 3’ from the tigStore retrieval above – it should be reporting a unitig without consensus.

b

[Ben, sorry for the duplicate, forgot to send to the list]



On 5/22/13 11:28 AM, "Ben Elsworth" <el...@gm... <http://el...@gm...> > wrote:

Hi,

I am having an issue with the consensus step as part of MaSuRCA. One unitig fails and I have tried a number of methods to correct it, including rearranging, splitting and even removing it. All of these methods fix the alignment issue and produces a successful outcome when I test it:

utgcns -g genome.gkpStore -t genome.tigStore 1 3 -T unitig8049

Based on this I insert the updated tig and compute the new consensus sequence:

tigStore -g genome.gkpStore -t genome.tigStore/ 1 -up 3 -R unitig8049


utgcns -g genome.gkpStore -t genome.tigStore 1 3 -u 8049


However, when I rerun runCA I get the following error from the cgw step:


Reading unitigs.


...processed 100000 unitigs.
ERROR:  Unitig 8049 has no placement; probably not run through consensus.


cgw: Input_CGW.C:117: int ProcessInput(int, int, char**): Assertion `1 == GetNumIntUnitigPoss(uma->u_list)' failed.





How can I make sure the new unitig arrangement is found?

Cheers,

Ben