randomeffect / ngopt Goto Github PK

I am trying to assemble the test phiX using a Linux Supercomputer system.  

I works good until it creates the xx.contigs.fasta file and then it appear to 
stop.  The end of the output looks like this:

[bwa_aln_core] 3128 sequences have been processed.
[a5] java -jar GetInsertSize.jar test.out.raw1.sub.pe.sam
The java class could not be loaded. java.lang.UnsupportedClassVersionError: 
(org/halophiles/assembly/InsertSizeExporter) bad major version at offset=6
Use of uninitialized value $ins_n in numeric gt (>) at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1493, 
<IN> line 2.
Use of uninitialized value $ins_n in concatenation (.) or string at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1499, 
<IN> line 2.
[a5] Discarding estimate. Not enough data points: 
Use of uninitialized value $ins_mean in multiplication (*) at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1500, 
<IN> line 2.
Use of uninitialized value in concatenation (.) or string at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1145, 
<IN> line 2.
Use of uninitialized value in concatenation (.) or string at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1145, 
<IN> line 2.
[a5] Printing preprocessed library file to test.out.preproc.libs
[a5] Processed libraries:
     raw1:
      id=raw1
      p1=phiX_p1.fastq.pp.ec.fastq
      p2=phiX_p2.fastq.pp.ec.fastq
      ins=0
      err=0
      nlibs=1
      libfile=test.out.library_1.txt
[a5_s3] Scaffolding contigs from test.out.contigs.fasta with SSPACE
[a5_s3] Scaffolding contigs from test.out.contigs.fasta with SSPACE
[a5] Total contig length 5469
[a5] raw1: Insert 0, coverage 49.20, expected links 0
Can't take log of 0 at 
/home/uahlmm/ngopt_a5pipeline_linux-x64_20120518/bin/a5_pipeline.pl line 1426, 
<READFILE> line 12516.



Is it appears that there is an error on how it calculates the insert size.  Is 
it something that needs to be install on the machine?

thank you

luciano

First off, thanks for creating the pipeline. My tests comparing de novo 
illumina paired end assemblies of methanogen genomes versus closed (or almost 
closed) versions of the genomes shows that your pipeline works better than 
Velvet, Newbler, CLC Genomics, and SPADES in terms of contiguity and fidelity 
(ie miscalled bases).

I've been using different numbers of reads for input and noticed a possible bug 
with the insert size estimation. When using 2 million read pairs, the insert 
size is estimated as 100bp. However, when using greater numbers of reads (4 
million - 10 million), the insert size is ~430bp, which is what it should be.

I've tried supplying an insert size in a library file, but since the insert 
size can be estimated (i.e. 100bp), my provided insert size is not used.

Thanks again for constructing the pipeline.

Nick

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?
I'm trying to assemble a bacterial genome.

What version of the product are you using? On what operating system?
I'm using ngopt_a5pipeline_linux-x64, on a linux operating system.

Please provide any additional information below.

My email: [email protected]

I've been using the A5 pipeline with much success until I attempted an assembly 
with 250 bp reads from the Illumina MySeq.  This caused a memory pointer error 
in IDBA which subsequently crashed.  This error has been previously reported 
for IDBA (http://code.google.com/p/hku-idba/issues/detail?id=2).

By setting the '--long' option for IDBA and giving the '-r' option a blank file 
I was able to run the assembly without the memory error.  However, in the 
pipeline I'm not sure how this can be specified if one has a file with longer 
reads.  

I'm getting great results with much less hands-on time than I was doing 
previously and would like to continue using the A5 pipeline. Is it possible to 
incorporate this in future versions of the pipeline?

Thanks for making a great piece of software!

What steps will reproduce the problem?
1. yum install glibc-static
2. perform a ``make`` 

What is the expected output? What do you see instead?

The expected output would be an executable named ``repair``.  

What I got is listed here: 

https://gist.github.com/3005821

What version of the product are you using? On what operating system?

Latest trunk of the source, on RHEL 5.1 

I found a bug with the 'get_phred64' subroutine.
If a 'high quality' read in Phred+33 fastq format is provided (i.e. all bases 
in read have ACSII 64-74), then the subroutine defines the fastq format as 
Phred+64. I made the following changes to the subroutine at it appears to call 
the correct format in all cases that I tested:

sub get_phred64{
        my $tail_file = shift;
        my $qline = `head -n 1000 $tail_file | tail -n 1`;
        chomp $qline;
        my $phred64 = 1; 
        my($b64, $a74) = (0,0); 
        for my $q (split(//,$qline)){
                $b64++ if ord($q) < 64;
                $a74++ if ord($q) > 74;
                #$phred64 = 0;
                #last;
        }    
        if($b64 > 0 && $a74 > 0){ die " ERROR: found qual scores specific to Phred+33 & Phred+64 format"; }
        elsif($b64 > 0 && $a74 == 0){ $phred64 = 0; } # if Phred+33
        elsif($a74 > 0 && $b64 == 0){ $phred64 = 1; } # if Phred+64
        elsif($b64 == 0 && $a74 == 0){ $phred64 = 0; }  # if all between 64 to 73, assuming high Phred+33 scores
        else{ die " Logic error\n", $!; }

        return $phred64;
}



Nick