Re: [wgs-assembler-users] Erroneous ASM file

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

Hi, again-

(I guess I should have replied to this one instead)

We changed the way the bogart unitigger detects and handles repeats.  Which
versions of the code are you comparing?  It might be an obscure bug, but
more likely, it's the unitig changes.

We're preparing a release, but in general, using the latest svn is
recommended.  If anything, that will make the bugs easier to find and fix,
and easier for you to restart after the fix.

b



On 10/3/13 4:45 AM, "Mayank Mahajan" <may...@ic...> wrote:

> Hej Brian,
> wow! I was stuck for three weeks with this consensus problem. Thats called
> extreme bad luck.
> 
> But have you check the GC content with the latest version. because when I
> calculate it from the scf.fasta its 2% higher than what the caqc.pl shows me.
> 
> Also, usually celera gives very stable assemblies when you do no change the
> data and parameters. But the new version is giving me a bit different
> assemblies. It seems that these builds are not completely reliable. Can you
> guide me which build I must choose and how to download it.
> 
> WarmRegards,
> Mayank
> 
> On 30 sep 2013, at 15:04, "Walenz, Brian" <bw...@jc...> wrote:
> 
>> Dang, I think you might have hit a stupid bug I introduced and then fixed
>> much later than I'm happy to admit.
>> 
>> Broken in this:
>> 
>> r4393 | brianwalenz | 2013-08-24 03:46:56 -0400 (Sat, 24 Aug 2013) | 2 lines
>> Add runCA option cgwPreserveConsensus.
>> 
>> Fixed in this:
>> 
>> r4406 | brianwalenz | 2013-09-06 18:42:08 -0400 (Fri, 06 Sep 2013) | 3 lines
>> The cgwPreserveConsensus default value was incorrect resulting in cgw always
>> retaining the consensus sequence, and 8-consensus never recomputing it.
>> 
>> Does 'svn info' show a revision between those two?
>> 
>> 
>> 
>> On 9/30/13 8:12 AM, "Mayank Mahajan" <may...@ic...> wrote:
>> 
>>> Hello,
>>> I have been using the unstable release of WGS assembler. I have some
>>> really good assemblies as per my post assembly checks.
>>> The problem is that the {CCO tags in the asm file are all loosing the
>>> information whenever they have more than one unitig in the contig.
>>> Whenever there is more than one unitig in the contig the quality
>>> values of the whole consensus just become zero. The contigs loose all
>>> the gap information which takes into consideration the indels in the
>>> reads. And respectively, all the reads also loose the indel
>>> information in the contigs.
>>> 
>>> Regards,
>>> Mayank Mahajan
>> 
>