[rhall]

From the log that you posted, the seed length is being automatically set (based on 30x of reads for the input genome size), so the 6000 is ignored, although with a 2500 mean subread length it is possible that you will still have significant coverage of reads >6kb.
Can you check the output directory for the ./data/corrected.fasta file to make sure that the preassembly is working. Also if you could post the ./logs/P_CeleraAssembler/runCaHgap.log as that is the specific job that failed.

[tonybert]

If the subread length is ~2500, then I should probably decrease the minimum seed length, correct? The default is 6000. Could this be why its failing?

[tonybert]

Yes, see atttached, this is from the smrt analysis portal.

[rhall]

The subread length will be the limiting factor, but your coverage is sufficient for PacBio only assembly. You should be able to run HGAP.3 on the cloud instance of SMRT Analysis without using Star cluster, although it will require one of the larger computational instances.
For the HGAP.2 run, was that on a cloud instance? Do you have any logs, specific errors?

[tonybert]

Hi GenoMax, this is from the smrt portal.
Mean Subread length 2,677 N50 3,055
Total Number of Bases 447,142,427 Number of Reads 166,982

I was trying to run HGAP.2, but it run never completed, it failed.

[tonybert]

Hi GenoMax, the output from our PacBio sequencing facility consists of a directory that contains another directory (Analysis Results), filtered_subreads.fastq.gz, DS_Store, and a file with a .xml extension. Analysis results has all the .bax.h5 and .bas.h5 files. Would RS_subreads be something that would come off of the smrt portal?

I am in the "PacBio should be enough" camp but to be fair PacBio data tonybert has needs to be of good quality. The "sweet spot" for getting a good assembly appears to be library specific in our hands.

@tonybert: Can you post stats from a "RS_subreads" run for your SMRTcell?

[rhall]

I totally agree, the point I wanted to make was that if you do have plenty of coverage of PacBio (likely given the size of the genome), regardless of subread length, a hybrid approach will not improve the assembly as it does not add any long range information. It is the long range information that helps complete assemblies. A hybrid approach only helps when you have limited coverage.

[GenoMax]

I am in the "PacBio should be enough" camp but to be fair PacBio data tonybert has needs to be of good quality. The "sweet spot" for getting a good assembly appears to be library specific in our hands.

@tonybert: Can you post stats from a "RS_subreads" run for your SMRTcell?

[rhall]

It is extremely unlikely that a hybrid assembly will give better results than all PacBio, particularly if the Pacbio assembly is not coverage limited (>40x per genome).

http://www.biomedcentral.com/content/pdf/gb-2013-14-9-r101.pdf

[gconcepcion]

Thanks for the prompt response. So its more of an environment issue?

For the error message that you indicated, yes, it is an environment thing, and from what I can tell you have PBS configured in your environment as the job scheduler instead of SGE.
Celera Assembler (last time I checked: http://wgs-assembler.sourceforge.net...ndex.php/RunCA) is only able to run on SGE or LSF, so PBS would pose a problem.

I would like to echo rhall's sentiment though, that if your genome size is only 1.8-2.0 Mbp, why are you even bothering with Hybrid assembly? If you have 1 SMRTCell of data, you should have PLENTY of excess coverage to run HGAP_3 and get a MUCH better result than any hybrid illumina-pacbio strategy.

Assemble with pacbio and use the Illumina short reads to validate the assembly.

[tonybert]

Hi rhall, we tried HGAP with the smrt cell for the 3 genomes. We were expecting to have one contiguous, single contig after HGAP assembly. This was not the case. I have to look back at my notes, but I believe we had between 6-9 contigs for per genome. Additionally, we were under the impression that error-correcting with Illumina would lead to higher quality, higher accuracy genome draft genomes. That said, my initial HGAP assembly was run using the SMRT portal (v 1.3 i believe) about a year or more ago, i didn't really put to much effort to tuning the assembly parameters.

[tonybert]

Thanks for the prompt response. So its more of an environment issue?

[rhall]

Out of interest, why are you trying to use illumina reads for a hybrid assembly? For such a small genome 1 SMRT Cell of data should be more than enough to assembly the PacBio data denovo.

[gconcepcion]

Hi Tony,

I'm not familiar with STAR cluster, or how/which job schedulers it is configured for, however I can tell you that particular error message is because CeleraAssembler is configured to run on SGE, however for whatever reason, the binaries that are in your path are for PBS.

This is a confusing issue as both SGE && PBS have some similar binary names, which can result in the user being confused what job scheduler is actually installed.

To illustrate what I mean, see this example:

### SGE is configured as default here (this should fail because I don't actually have your script on hand)
-bash-3.2$ qsub -A assembly -pe threads 4 -cwd -N "pBcR_asm" -j y -o /home/ubuntu/wgs-8.3rc1/Linux-amd64/bin//tempec_pacbio
Unable to read script file because of error: no input read from stdin

### When I add the PBS job scheduler binaries to my PATH (ahead of our SGE binaries) you see the message that you referenced:
-bash-3.2$ export PATH=/opt/pbs/bin:$PATH
-bash-3.2$ qsub -A assembly -pe threads 4 -cwd -N "pBcR_asm" -j y -o /home/ubuntu/wgs-8.3rc1/Linux-amd64/bin//tempec_pacbio
qsub: illegal -p value
qsub: illegal -c value ""
usage: qsub [-a date_time] [-A account_string] [-b secs]
[-c [ none | { enabled | periodic | shutdown |
depth=<int> | dir=<path> | interval=<minutes>}... ]
[-C directive_prefix] [-d path] [-D path]
[-e path] [-h] [-I] [-j oe] [-k {oe}] [-l resource_list] [-m n|{abe}]
[-M user_list] [-N jobname] [-o path] [-p priority] [-P proxy_user] [-q queue]
[-r y|n] [-S path] [-t number_to_submit] [-T type] [-u user_list] [-w] path
[-W additional_attributes] [-v variable_list] [-V ] [-x] [-X] [-z] [script]

[gconcepcion]

qsub: illegal -p value
qsub: illegal -c value ""

Hi Tony,

I'm not familiar with STAR cluster, or how/which job schedulers it is configured for, however I can tell you that particular error message is because CeleraAssembler is configured to run on SGE, however for whatever reason, the binaries that are in your path are for PBS.

This is a confusing issue as both SGE && PBS have some similar binary names, which can result in the user being confused what job scheduler is actually installed.