thankyou for ultra rapid response
yes I have previously used Mira locally for smallish genomes with low coverage
and it was delightfully quick in both denovo an dmapping modes. I'm currently
running on cluster with linux OS, I don't how disks are formatted, using slurm
queuing system (6 CPUs for 4 hr), ... attached is log in case it has meaningful
info. The manifest file as requested is below.
##############################
###MIRA MAPPING ILLUMINA CONFIG FILE###
##############################
# basic instructions
project = P4710_101_mapd2_AAA028-C07
job = genome,mapping,accurate
# defining reference template
readgroup
as_reference
data = /proj/b2016272/private/pelgbrc_public_genomes/gbk/AAA028-C07.gbk
strain = AAA028-C07
# setting general parameters for assembly
parameters = COMMON_SETTINGS \
-GE:not=5:mps=64 \
-AS:sep=on:nop=0:rbl=1:sd=off \
-SB:tor=off \
-CL:ascdc=off \
-CO:mr=on \
-DI:trt=/scratch/ \
-NW:cnfs=stop:cdrn=stop:ctp=stop:cac=stop:cmpm=warn \
-OUT:orc=off \
SOLEXA_SETTINGS = -AS:epoq=off:mrl=30:ardml=100:mrpc=2 \
-SB:bnb=on -OUT:sssip=on \
--hirep_good \
--noclipping
# defining input data
readgroup = singlereadHiSeq
data = ../fragments/rcrtd_frags_frhit_fasta/P4710_101_1U_frhit_rcrtdx.fna
../fragments/rcrtd_frags_frhit_fasta/P4710_101_2U_frhit_rcrtdx.fna
../fragments/rcrtd_frags_frhit_fasta/P4710_101_1P1_frhit_rcrtdx.fna
../fragments/rcrtd_frags_frhit_fasta/P4710_101_2P2_frhit_rcrtdx.fna
technology = solexa
parameters = -CO:mrpg=4
default_qual=30
Rhiannon Mondav | 9-18 må, ti, tors, fre | Evolutionary Biology Centre, Uppsala
University, Sweden
________________________________
From: mira_talk-bounce@xxxxxxxxxxxxx [mira_talk-bounce@xxxxxxxxxxxxx] on behalf
of Bastien Chevreux [bach@xxxxxxxxxxxx]
Sent: 29 August 2016 14:42
To: mira_talk@xxxxxxxxxxxxx
Subject: [mira_talk] Re: (no subject)
On 29 Aug 2016, at 6:09 , Rhiannon Mondav
<rhiannon.mondav@xxxxxxxxx<mailto:rhiannon.mondav@xxxxxxxxx>> wrote:
[…]
I am a little bit at loss here with this error report, because there are
several things I scratch my head.
on an assembly (mapping) of small genome ~1M bacteria with x10 to x20 coverage
on Mira 4.0.2. Process got to 'ATG PREDICTIONS' before timing out on my cluster
job.
This is the first thing. I regularly use MIRA for mapping against bacteria. I
don’t know by the exact times by heart, but a 4M bacterium with ~80x coverage
is done in less than 30 minutes (8 cores).
You have a 1M bacterium which times out at 20x max??? This is *very* strange.
I attempted to utilise the fabulous resume function. The log file got to 'File
/ directory output names: ..... Wiggle: P4710_101_mapd2_AAA028-C07_out.wig'
when Mira issued the following error:
I thought I’d blocked resume in mapping mode as there are oddities in this case
I haven’t had the time to iron out. Maybe I did that only later though.
[…|
Deleting old directory
P4710_101_mapd2_AAA028-C07_assembly/P4710_101_mapd2_AAA028-C07_d_results ...
done.
Creating directory
P4710_101_mapd2_AAA028-C07_assembly/P4710_101_mapd2_AAA028-C07_d_results ...
done.
A 'standard' exception occured (that's NOT normal):
boost::filesystem::create_symlink: File exists:
"/scratch//P4710_101_mapd2_AAA028-C07_d_tmp_Nu6X7Z",
"P4710_101_mapd2_AAA028-C07_assembly/P4710_101_mapd2_AAA028-C07_d_tmp”
This is another thing which “should not happen” under normal circumstances. The
only times I got reports about this was indeed when people ran on some weird
NFS or other network based file systems. Is that the case for you?
Could you please share the manifest file you used?
B.
Attachment:
slurm-8430387.out
Description: slurm-8430387.out
