[jkaralius]

am trying to use smrt in my SGE cluster after installing am trying to run smrtpipe.py am getting the following error Traceback (most recent call last):
File "/share/apps/smrtanalysis/install/smrtanalysis_2.3.0.140936/analysis/bin/ smrtpipe.py", line 11, in
from SMRTpipe.SmrtPipeMain import SmrtPipeMain, _sanityCheck
ImportError: No module named SMRTpipe.SmrtPipeMain

This question is covered in GitHub:

https://github.com/PacificBiosciences/SMRT-Analysis/issues/171

[madhubioinfo]

am trying to use smrt in my SGE cluster after installing am trying to run smrtpipe.py am getting the following error Traceback (most recent call last):
File "/share/apps/smrtanalysis/install/smrtanalysis_2.3.0.140936/analysis/bin/ smrtpipe.py", line 11, in
from SMRTpipe.SmrtPipeMain import SmrtPipeMain, _sanityCheck
ImportError: No module named SMRTpipe.SmrtPipeMain

[rhall]

Edward,
What version of SMRT Analysis are you using? This is a known bug, but I thought it was fixed.

[oakeley]

Exiting smrtpipe last error: time data

Dear all,
I just spent a few hours trying to figure out why jobs on my test install of smrtpipe failed immediately (everything looked OK). Google gave me nothing do I am posting here to help anyone who gets an error like this:
"Exiting smrtpipe last error: time data 'Sam Jan 18 10:47:32 UTC 2014' does not match"

My Linux box is set up with German (Swiss) for the language for no good reason except that I live in Switzerland...

If you do this then the date settings are in German (Sam = Samstag = Saturday)

The smrtpipe will only run if you change (system wide) your language settings to US English. Do a reboot just to be sure and then you are good to go.

Kind of annoying but now you know.

Good luck and have fun

Edward

[zhoufan]

Hi rhall,
Thanks ! It works after i changed the OS.

[rhall]

I believe SMRT Analysis requires a 64bit OS.

[zhoufan]

Hi everyone,
I am trying to install SMRT v2.0.1 on ubuntu 10.04 i386 server.
when Perform fresh installation with the
"./configure_smrtanalysis.sh"command, an error returned.The error message is :
"./configure_smrtanalysis.sh:line 29:/smrtanalysis-2.0.1/redist/python2.7/bin/python:cannot execute binary file".

can anyone help me out there? thanks in advance!

[sagarutturkar]

Version 2.0.1 generated improved assembly

Hi rhall,

Thanks for your reply. After update to SMRTanalysis version 2.0.1, I was able to use default HGAP method to assemble genome as single contig. Same genome was assembled to 3 contigs in SMRTanalysis version 2.0. There is definitely some improvement in HGAP algorithm. I have seen improvement in asembly stats for some other genomes too. I recommend update to version 2.0.1 to all users.

Initially, we tried to install SMRTanalysis on redhat system. But got lot of errors related to python and never able to get this running on redhat. I suggest installing it on recommended version rather than spending time for troubleshooting later.

Thanks

[GenoMax]

Can I ask a quick tad unrelated. I have an older linux machine running redhat version 5.3. The smartanalysis 2.01 for centos version 5.3 should work ok right?

It does work. We are running 2.0.1 on Rocks v.5.3 and 5.4 clusters. There is a separate installer for CentOS 5.3 which you should use.

[rhall]

It it definitely worth trying, but I'm not an expert on the subtle differences between centos and redhat.

[tfahland]

Can I ask a quick tad unrelated. I have an older linux machine running redhat version 5.3. The smartanalysis 2.01 for centos version 5.3 should work ok right?

[rhall]

If your PreAssembled yield is really good, and you are using an automatically calculated seed length, using a slightly longer seed, provided that the preassembled #bases is still ~15x may give better results. Also toggling Allow Partial Alignments will have a significant effect, which way depends on data. If the PreAssembled read yield is low, decreasing the RQ filter to 0.75 may improve results. The blasr mapping parameters will likely not have much of an impact in going from 3 contigs to 1.

[sagarutturkar]

The genome size is 4.3 MB while longest contig is 3.5 MB. smallest one is 12 KB. We were able to get this with default parameters while our external data_providers were able use same data and get down to 1 contig with HGAP method. I am waiting for their reply about how they tweak the parameters. However, I though meanwhile I could try some tweaking which could help me to improve the assembly. May be updating the mapping parameters would help?

I am trying to get update to v 2.0.1 with system admins.

Many Thanks
Sagar

[rhall]

2.0.1 will likely not improve HGAP results over 2.0.0 for old data, but recommended if you are going to process data from P4 enzyme.

[rhall]

Given that you are getting only 3 contigs, tweaking HGAP parameters will likely not improve the assembly. I would try to understand why / what the 3 contigs are. Are the 3 contigs all significant length? or does one contig make up most of the expected genome length? Looking at Dot plots of the contigs against one another will indicated if the contigs are being broken due to un-resolvable repeat structure / ambiguous overlap, in which case the only way to join the contigs will likely be producing longer reads / library. Also looking at the actual alignment of the raw reads to the contigs can indicate if the contig ends have broken due to repeats, indicated by mapQV=0 (red in SMRT View) reads mapped to the end of contigs.
Also Celera Assembler can often be quite conservative in overlapping. If the 3 contigs do actually unambiguously overlap, minimus2 can be used to complete the assembly.