<= /div>

Hi all,

I am a newbie in SeqAn. I want t= o start by thanking all for this awesome library, the developers for their = great work and the users for their valuable feedback.

I am trying to load some bam file records into a FragSt= ore and although SeqAn has some excellent tutorials I failed to achieve thi= s. Since I am sure this problem have been solved a while ago I decided to a= sk here. So my problem can be formulated in 3 simple steps:

1) open a bam file

2) read a bam file record<= /div>

3) IF bam file record passes my filter THEN load it into FragStor= e

Any hints, tips or documentation I should read t= hat can help me achieve this?

thanks,

val

--047d7b10d0db57e53f04de439d2d-- From weese@campus.fu-berlin.de Wed Jun 05 10:02:42 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Uk8g4-000wbx-Mp>; Wed, 05 Jun 2013 10:02:40 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Uk8g4-000RYT-Ku>; Wed, 05 Jun 2013 10:02:40 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Uk8g4-0049cP-Cu>; Wed, 05 Jun 2013 10:02:40 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Wed, 5 Jun 2013 10:02:38 +0200 From: "Weese, David" To: SeqAn Development Thread-Topic: [Seqan-dev] Suffix links Thread-Index: AQHOXi5IWOpR/g1lGk66mxO0iB0NFpkmqDKA Message-ID: <3EFAA06B-0BDA-4EE6-92DB-8FE950ACE456@fu-berlin.de> References: <51A8EE42.8030805@mail.cryst.bbk.ac.uk> In-Reply-To: <51A8EE42.8030805@mail.cryst.bbk.ac.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3EFAA06B0BDA4EE692DB8FE950ACE456fuberlinde_" MIME-Version: 1.0 Date: Wed, 05 Jun 2013 10:02:37 +0200 X-Original-Date: Wed, 5 Jun 2013 08:02:37 +0000 X-Originating-IP: 130.133.170.201 X-ZEDAT-Hint: A X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370419360-00000A3F-DD5FDBC1/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.044295, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-50.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] Suffix links X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:02:42 -0000 --_000_3EFAA06B0BDA4EE692DB8FE950ACE456fuberlinde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, we not yet have suffix links in our suffix trees. There are two papers prop= osing how to post-compute a suffix link table on top of an enhanced suffix = array: Abouelhoda, M., Kurtz, S., & Ohlebusch, E. (2004). Replacing suffix trees w= ith enhanced suffix arrays. Journal of Discrete Algorithms, 2(1), 53=9686. or on any suffix tree/array: Maa=DF, M. G. (2007). Computing suffix links for suffix trees and arrays. I= nformation Processing Letters, 101(6), 250=96254. doi:10.1016/j.ipl.2005.12= .012 I haven't looked how they are implemented and which one is faster or more p= ractical for large datasets. Maybe you can use the implementation and tell = us about your experiences or we'll find a Bsc/MSc. student to try them out. Cheers, David Am 31.05.2013 um 20:38 schrieb John Reid >: Hi, I had a little google for this but I didn't find the answer. I have an algorithm which should run quickly on a suffix tree or array. However in the algorithm I will need to move from a node for say the suffix GCCGAA to the node for CCGAA. This is obviously expensive in a normal suffix tree. However I think that some suffix tree construction algorithms create suffix links (perhaps Ukkonen's algorithm) that do exactly this. Does SeqAn contain such algorithms and how can I access the suffix links after construction? Thanks, John. _______________________________________________ seqan-dev mailing list seqan-dev@lists.fu-berlin.de https://lists.fu-berlin.de/listinfo/seqan-dev --_000_3EFAA06B0BDA4EE692DB8FE950ACE456fuberlinde_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E23E145A0EB1E449697C9A7F846B53B@campus.fu-berlin.de> Content-Transfer-Encoding: quoted-printable Hi John,

we not yet have suffix links in our suffix trees. There are two papers= proposing how to post-compute a suffix link table on top of an enhanced su= ffix array:

Abouelhoda, M., Kurtz, S., & Ohlebusch, E. (2004). Replacing suffix= trees with enhanced suffix arrays. Journal of Discrete Algorithms, 2(1), 53=9686.

or on any suffix tree/array:

Maa=DF, M. G. (2007). Computing suffix links for suffix trees and array= s. Information Processing Letters, 101(6), 250=96254. doi:10.101= 6/j.ipl.2005.12.012

I haven't looked how they are implemented and which one is faster or m= ore practical for large datasets. Maybe you can use the implementation and = tell us about your experiences or we'll find a Bsc/MSc. student to try them= out.

Cheers,

David

Am 31.05.2013 um 20:38 schrieb John Reid <j.reid@mail.cryst.bbk.ac.uk>:

Hi,

I had a little google for this but I didn't find the answer. I have an
algorithm which should run quickly on a suffix tree or array. However in the algorithm I will need to move from a node for say the suffix GCCGAA
to the node for CCGAA. This is obviously expensive in a normal suffix
tree. However I think that some suffix tree construction algorithms
create suffix links (perhaps Ukkonen's algorithm) that do exactly this.
Does SeqAn contain such algorithms and how can I access the suffix links after construction?

Thanks,
John.

_______________________________________________
seqan-dev mailing list
seqan-dev@lists.fu-berlin.d= e
https://lists.fu-berlin.de/listinfo/seqan-dev

--_000_3EFAA06B0BDA4EE692DB8FE950ACE456fuberlinde_-- From jer15@hermes.cam.ac.uk Wed Jun 05 10:32:15 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Uk98d-0010H8-8q>; Wed, 05 Jun 2013 10:32:11 +0200 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Uk98d-001DEy-5q>; Wed, 05 Jun 2013 10:32:11 +0200 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cpc6-dals15-2-0-cust115.hari.cable.virginmedia.com ([82.35.196.116]:35807 helo=[192.168.1.7]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:jer15) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1Uk98a-00062H-9J (Exim 4.80_167-5a66dd3) for seqan-dev@lists.fu-berlin.de (return-path ); Wed, 05 Jun 2013 09:32:08 +0100 Message-ID: <51AEF788.90309@mail.cryst.bbk.ac.uk> Date: Wed, 05 Jun 2013 09:32:08 +0100 From: John Reid User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: SeqAn Development References: <51A8EE42.8030805@mail.cryst.bbk.ac.uk> <3EFAA06B-0BDA-4EE6-92DB-8FE950ACE456@fu-berlin.de> In-Reply-To: <3EFAA06B-0BDA-4EE6-92DB-8FE950ACE456@fu-berlin.de> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: "J.E. Reid" X-Originating-IP: 131.111.8.149 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1370421131-00000A3F-4C5E6424/3895166851-0/0-1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.116349, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=2.1 required=5.0 tests=FU_XPURGATE_SUSP, HTML_MESSAGE, MIME_HTML_ONLY X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Algerien.ZEDAT.FU-Berlin.DE X-Spam-Level: xx Subject: Re: [Seqan-dev] Suffix links X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:32:15 -0000 Hi David,

Thanks for the pointers. I'll have a look. I'll probably use some slow method of creating suffix links until I have checked if my model is good. If it is I'll have a look at how to get the links efficiently.

Cheers,
John.

On 05/06/13 09:02, Weese, David wrote:

Hi John,

we not yet have suffix links in our suffix trees. There are two papers proposing how to post-compute a suffix link table on top of an enhanced suffix array:

Abouelhoda, M., Kurtz, S., & Ohlebusch, E. (2004). Replacing suffix trees with enhanced suffix arrays. Journal of Discrete Algorithms, 2(1), 53–86.

or on any suffix tree/array:

Maaß, M. G. (2007). Computing suffix links for suffix trees and arrays. Information Processing Letters, 101(6), 250–254. doi:10.1016/j.ipl.2005.12.012

I haven't looked how they are implemented and which one is faster or more practical for large datasets. Maybe you can use the implementation and tell us about your experiences or we'll find a Bsc/MSc. student to try them out.

Cheers,

David

Am 31.05.2013 um 20:38 schrieb John Reid <j.reid@mail.cryst.bbk.ac.uk>:

Hi,

I had a little google for this but I didn't find the answer. I have an
algorithm which should run quickly on a suffix tree or array. However in
the algorithm I will need to move from a node for say the suffix GCCGAA
to the node for CCGAA. This is obviously expensive in a normal suffix
tree. However I think that some suffix tree construction algorithms
create suffix links (perhaps Ukkonen's algorithm) that do exactly this.
Does SeqAn contain such algorithms and how can I access the suffix links
after construction?

Thanks,
John.

_______________________________________________
seqan-dev mailing list
seqan-dev@lists.fu-berlin.de
https://lists.fu-berlin.de/listinfo/seqan-dev
_______________________________________________
seqan-dev mailing list
seqan-dev@lists.fu-berlin.de
https://lists.fu-berlin.de/listinfo/seqan-dev

From lienhard@molgen.mpg.de Wed Jun 05 11:44:09 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkAGG-001Fx7-Gs>; Wed, 05 Jun 2013 11:44:08 +0200 Received: from mx1.molgen.mpg.de ([141.14.16.9]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkAGG-001XEt-FC>; Wed, 05 Jun 2013 11:44:08 +0200 Received: from agrajag.molgen.mpg.de (agrajag.molgen.mpg.de [141.14.24.233]) by mx.molgen.mpg.de (Postfix) with ESMTP id 689DA8001FB72 for ; Wed, 5 Jun 2013 11:44:07 +0200 (CEST) Message-ID: <51AF0867.3070509@molgen.mpg.de> Date: Wed, 05 Jun 2013 11:44:07 +0200 From: Matthias Lienhard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130506 Thunderbird/17.0.5 MIME-Version: 1.0 To: SeqAn Development Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 141.14.16.9 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370425448-00000A3F-78A3B8F1/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.009709, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 09:44:09 -0000 Hi, when runnig razers3 on my paired end HiSeq fastq files I get the following errors razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq terminate called recursively terminate called recursively Aborted or terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted It seems as memory usage is very high (>50gb). Each of the fastq files is about 7 gb. When I take the first 100000 reads, the razers3 seems to work fine. However, I don't want to split the files in small chucks and merge them together afterwards (because of disk usage and convenience - I have about 50 samples to process) Is there another way to handle this issue? Also, it would be very convienient if gzipped fastq files could be used as input directly - and output in bam-format would be nice as well. Best wishes, Matthias From jer15@hermes.cam.ac.uk Thu Jun 06 15:32:00 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkaII-00112D-Df>; Thu, 06 Jun 2013 15:31:58 +0200 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkaII-002FTc-Ah>; Thu, 06 Jun 2013 15:31:58 +0200 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from wifi-host-45.mrc-bsu.cam.ac.uk ([193.60.87.45]:57071) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:jer15) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UkaIG-0006KB-ir (Exim 4.80_167-5a66dd3) for seqan-dev@lists.fu-berlin.de (return-path ); Thu, 06 Jun 2013 14:31:56 +0100 Message-ID: <51B08F4C.1000406@mail.cryst.bbk.ac.uk> Date: Thu, 06 Jun 2013 14:31:56 +0100 From: John Reid User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: SeqAn Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: "J.E. Reid" X-Originating-IP: 131.111.8.133 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370525518-00000A3F-34C51347/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000162, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] SeqAn with valgrind X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:32:00 -0000 Hi all, Is valgrind a tool that people use with SeqAn much? Is SeqAn free of any spurious (or not so spurious) leaks? Does anyone have a valgrind suppressions file I might find useful with gcc-4.6? For instance I have the following reported by "valgrind --leak-check=full" when using a TopDown iterator with an ESA. I'm guessing it is not a problem but I'd like to see what others think. Getting rid of any valgrind warnings generated by SeqAn will help me locate any bugs I might have in my code. Thanks again for a fantastic library, John. ==16613== Memcheck, a memory error detector ==16613== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==16613== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==16613== Command: /usr/bin/python /usr/bin/nosetests ../cacto/ ==16613== ..==16613== Conditional jump or move depends on uninitialised value(s) ==16613== at 0x9FD1E6F: void seqan::createChildtab >, seqan::String > >(seqan::String >&, seq an::String > const&) (index_childtab.h:261) ==16613== by 0x9FC6278: bool seqan::indexCreate, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >(seqan::Index, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >&, seqan::Tag, seqan::Childtab) (index_shims.h:608) ==16613== by 0x9FB9373: bool seqan::indexCreate, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa , seqan::FibreChildtab_>(seqan::Index, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >&, seqan::Tag) (index_shims.h:615) ==16613== by 0x9FACCA2: bool seqan::indexRequire, seqan::Alloc >, seqan::Owner > >, seqan::IndexEs a, seqan::FibreChildtab_>(seqan::Index, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >&, seqan::Tag) (index_shims.h:664) ==16613== by 0x9FA0B93: void seqan::_indexRequireTopDownIteration, seqan::Alloc >, seqan::Owner > >, void>(seqan::Index, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >&) (index_esa_base.h: 303) ==16613== by 0x9F966DA: seqan::Iter, seqan::Alloc >, seqan::Owner > >, seqan::IndexEs a >, seqan::VSTree > >::Iter(seqan::Index, seqan::Alloc >, seqan::Owner > >, seqan::IndexEsa >&) (index_esa_stree.h:133) From weese@campus.fu-berlin.de Fri Jun 07 09:08:55 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqn8-001Jqa-9G>; Fri, 07 Jun 2013 09:08:54 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqn8-000DOK-6q>; Fri, 07 Jun 2013 09:08:54 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqn7-0017FI-Ko>; Fri, 07 Jun 2013 09:08:54 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 09:08:52 +0200 From: "Weese, David" To: SeqAn Development Thread-Topic: [Seqan-dev] SeqAn with valgrind Thread-Index: AQHOYrpSM8i5KrzWgEWdzi5lzBaOg5kptL8A Message-ID: References: <51B08F4C.1000406@mail.cryst.bbk.ac.uk> In-Reply-To: <51B08F4C.1000406@mail.cryst.bbk.ac.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_004_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_" MIME-Version: 1.0 Date: Fri, 07 Jun 2013 09:08:51 +0200 X-Original-Date: Fri, 7 Jun 2013 07:08:51 +0000 X-Originating-IP: 130.133.170.201 X-ZEDAT-Hint: A X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370588934-0000097E-EC6A77CA/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-50.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] SeqAn with valgrind X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:08:55 -0000 --_004_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_ Content-Type: multipart/alternative; boundary="_000_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_" --_000_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0Kd2UgdXNlIHZhbGdyaW5kIGluIG91ciBuaWdodGx5IGJ1aWxkcyB3aXRoIGdj Yy00LjYgdW5kZXIgTGludXggd2l0aG91dCBhbnkgaXNzdWVzIGFuZCBzbyBmYXIgaGF2ZW4ndCBz ZWVuIHRoYXQgZXJyb3IuIERvIHlvdSBnZXQgdGhlIHNhbWUgZXJyb3Igd2l0aCBvdXIgdGVzdHMs IGUuZy4gdGVzdF9pbmRleF9zdHJlZV9pdGVyYXRvcnMgb3IgdGVzdF9pbmRleF9yZXBlYXRzPw0K DQpJZiBub3QgY291bGQgeW91IHBsZWFzZSBjcmVhdGUgYSBidWcgdGlja2V0IHdpdGggc29tZSBz b3VyY2VzIGhvdyB0byByZXByb2R1Y2UgdGhlIGVycm9yPw0KDQpUaGFua3MsDQpEYXZlDQoNClBT OiBUaGlzIGlzIG91ciB2YWxncmluZCBzdXBwcmVzc2lvbiBmaWxlOg0KDQoNCi0tDQpEYXZpZCBX ZWVzZSAgICAgICAgICAgICAgICAgICAgIHdlZXNlQGluZi5mdS1iZXJsaW4uZGUNCkZyZWllIFVu aXZlcnNpdMOkdCBCZXJsaW4gICAgICAgIGh0dHA6Ly93d3cuaW5mLmZ1LWJlcmxpbi5kZS8NCklu c3RpdHV0IGbDvHIgSW5mb3JtYXRpayAgICAgICAgIFBob25lOiArNDkgMzAgODM4IDc1MTM3DQpU YWt1c3RyYcOfZSA5ICAgICAgICAgICAgICAgICAgICBBbGdvcml0aG1pYyBCaW9pbmZvcm1hdGlj cw0KMTQxOTUgQmVybGluICAgICAgICAgICAgICAgICAgICBSb29tIDAyMA0KDQpBbSAwNi4wNi4y MDEzIHVtIDE1OjMxIHNjaHJpZWIgSm9obiBSZWlkIDxqLnJlaWRAbWFpbC5jcnlzdC5iYmsuYWMu dWs+Og0KDQo+IEhpIGFsbCwNCj4NCj4gSXMgdmFsZ3JpbmQgYSB0b29sIHRoYXQgcGVvcGxlIHVz ZSB3aXRoIFNlcUFuIG11Y2g/IElzIFNlcUFuIGZyZWUgb2YgYW55DQo+IHNwdXJpb3VzIChvciBu b3Qgc28gc3B1cmlvdXMpIGxlYWtzPyBEb2VzIGFueW9uZSBoYXZlIGEgdmFsZ3JpbmQNCj4gc3Vw cHJlc3Npb25zIGZpbGUgSSBtaWdodCBmaW5kIHVzZWZ1bCB3aXRoIGdjYy00LjY/IEZvciBpbnN0 YW5jZSBJIGhhdmUNCj4gdGhlIGZvbGxvd2luZyByZXBvcnRlZCBieSAidmFsZ3JpbmQgLS1sZWFr LWNoZWNrPWZ1bGwiIHdoZW4gdXNpbmcgYQ0KPiBUb3BEb3duIGl0ZXJhdG9yIHdpdGggYW4gRVNB LiBJJ20gZ3Vlc3NpbmcgaXQgaXMgbm90IGEgcHJvYmxlbSBidXQgSSdkDQo+IGxpa2UgdG8gc2Vl IHdoYXQgb3RoZXJzIHRoaW5rLiBHZXR0aW5nIHJpZCBvZiBhbnkgdmFsZ3JpbmQgd2FybmluZ3MN Cj4gZ2VuZXJhdGVkIGJ5IFNlcUFuIHdpbGwgaGVscCBtZSBsb2NhdGUgYW55IGJ1Z3MgSSBtaWdo dCBoYXZlIGluIG15IGNvZGUuDQo+DQo+IFRoYW5rcyBhZ2FpbiBmb3IgYSBmYW50YXN0aWMgbGli cmFyeSwNCj4gSm9obi4NCj4NCj4gPT0xNjYxMz09IE1lbWNoZWNrLCBhIG1lbW9yeSBlcnJvciBk ZXRlY3Rvcg0KPiA9PTE2NjEzPT0gQ29weXJpZ2h0IChDKSAyMDAyLTIwMTEsIGFuZCBHTlUgR1BM J2QsIGJ5IEp1bGlhbiBTZXdhcmQgZXQgYWwuDQo+ID09MTY2MTM9PSBVc2luZyBWYWxncmluZC0z LjcuMCBhbmQgTGliVkVYOyByZXJ1biB3aXRoIC1oIGZvciBjb3B5cmlnaHQgaW5mbw0KPiA9PTE2 NjEzPT0gQ29tbWFuZDogL3Vzci9iaW4vcHl0aG9uIC91c3IvYmluL25vc2V0ZXN0cyAuLi9jYWN0 by8NCj4gPT0xNjYxMz09DQo+IC4uPT0xNjYxMz09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBk ZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykNCj4gPT0xNjYxMz09ICAgIGF0IDB4OUZE MUU2Rjogdm9pZA0KPiBzZXFhbjo6Y3JlYXRlQ2hpbGR0YWI8c2VxYW46OlN0cmluZzx1bnNpZ25l ZCBsb25nLCBzZXFhbjo6QWxsb2M8dm9pZD4gPiwNCj4gc2VxYW46OlN0cmluZzx1bnNpZ25lZCBs b25nLCBzZXFhbjo6QWxsb2M8dm9pZD4gPg0KPj4gKHNlcWFuOjpTdHJpbmc8dW5zaWduZWQgbG9u Zywgc2VxYW46OkFsbG9jPHZvaWQ+ID4mLCBzZXENCj4gYW46OlN0cmluZzx1bnNpZ25lZCBsb25n LCBzZXFhbjo6QWxsb2M8dm9pZD4gPiBjb25zdCYpDQo+IChpbmRleF9jaGlsZHRhYi5oOjI2MSkN Cj4gPT0xNjYxMz09ICAgIGJ5IDB4OUZDNjI3ODogYm9vbA0KPiBzZXFhbjo6aW5kZXhDcmVhdGU8 c2VxYW46OlN0cmluZ1NldDxzZXFhbjo6U3RyaW5nPHNlcWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVk DQo+IGNoYXIsIHNlcWFuOjpEbmFfPiwgc2VxYW46OkFsbG9jPHZvaWQ+ID4sDQo+IHNlcWFuOjpP d25lcjxzZXFhbjo6VGFnPHNlcWFuOjpEZWZhdWx0Xz4gPiA+LCBzZXFhbjo6SW5kZXhFc2ENCj4g PHZvaWQ+DQo+PiAoc2VxYW46OkluZGV4PHNlcWFuOjpTdHJpbmdTZXQ8c2VxYW46OlN0cmluZzxz ZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZA0KPiBjaGFyLCBzZXFhbjo6RG5hXz4sIHNlcWFuOjpB bGxvYzx2b2lkPiA+LA0KPiBzZXFhbjo6T3duZXI8c2VxYW46OlRhZzxzZXFhbjo6RGVmYXVsdF8+ ID4gPiwgc2VxYW46OkluZGV4RXNhPHZvaWQ+ID4mLA0KPiBzZXFhbjo6VGFnPHNlcWFuOjoNCj4g RmlicmVDaGlsZHRhYl8+LCBzZXFhbjo6Q2hpbGR0YWIpIChpbmRleF9zaGltcy5oOjYwOCkNCj4g PT0xNjYxMz09ICAgIGJ5IDB4OUZCOTM3MzogYm9vbA0KPiBzZXFhbjo6aW5kZXhDcmVhdGU8c2Vx YW46OlN0cmluZ1NldDxzZXFhbjo6U3RyaW5nPHNlcWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVkDQo+ IGNoYXIsIHNlcWFuOjpEbmFfPiwgc2VxYW46OkFsbG9jPHZvaWQ+ID4sDQo+IHNlcWFuOjpPd25l cjxzZXFhbjo6VGFnPHNlcWFuOjpEZWZhdWx0Xz4gPiA+LCBzZXFhbjo6SW5kZXhFc2ENCj4gPHZv aWQ+LA0KPiBzZXFhbjo6RmlicmVDaGlsZHRhYl8+KHNlcWFuOjpJbmRleDxzZXFhbjo6U3RyaW5n U2V0PHNlcWFuOjpTdHJpbmc8c2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQNCj4gY2hhciwgc2Vx YW46OkRuYV8+LCBzZXFhbjo6QWxsb2M8dm9pZD4gPiwNCj4gc2VxYW46Ok93bmVyPHNlcWFuOjpU YWc8c2VxYW46OkRlZmF1bHRfPiA+ID4sIHNlcWFuOjpJbmRleEVzYTx2b2lkPg0KPj4gJiwgc2Vx YW46OlRhZzxzZXFhbjo6RmlicmVDaGlsZHRhYl8+KSAoaW5kZXhfc2hpbXMuaDo2MTUpDQo+ID09 MTY2MTM9PSAgICBieSAweDlGQUNDQTI6IGJvb2wNCj4gc2VxYW46OmluZGV4UmVxdWlyZTxzZXFh bjo6U3RyaW5nU2V0PHNlcWFuOjpTdHJpbmc8c2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQNCj4g Y2hhciwgc2VxYW46OkRuYV8+LCBzZXFhbjo6QWxsb2M8dm9pZD4gPiwNCj4gc2VxYW46Ok93bmVy PHNlcWFuOjpUYWc8c2VxYW46OkRlZmF1bHRfPiA+ID4sIHNlcWFuOjpJbmRleEVzDQo+IGE8dm9p ZD4sDQo+IHNlcWFuOjpGaWJyZUNoaWxkdGFiXz4oc2VxYW46OkluZGV4PHNlcWFuOjpTdHJpbmdT ZXQ8c2VxYW46OlN0cmluZzxzZXFhbjo6U2ltcGxlVHlwZTx1bnNpZ25lZA0KPiBjaGFyLCBzZXFh bjo6RG5hXz4sIHNlcWFuOjpBbGxvYzx2b2lkPiA+LA0KPiBzZXFhbjo6T3duZXI8c2VxYW46OlRh ZzxzZXFhbjo6RGVmYXVsdF8+ID4gPiwgc2VxYW46OkluZGV4RXNhPHZvaWQ+DQo+PiAmLCBzZXFh bjo6VGFnPHNlcWFuOjpGaWJyZUNoaWxkdGFiXz4pIChpbmRleF9zaGltcy5oOjY2NCkNCj4gPT0x NjYxMz09ICAgIGJ5IDB4OUZBMEI5Mzogdm9pZA0KPiBzZXFhbjo6X2luZGV4UmVxdWlyZVRvcERv d25JdGVyYXRpb248c2VxYW46OlN0cmluZ1NldDxzZXFhbjo6U3RyaW5nPHNlcWFuOjpTaW1wbGVU eXBlPHVuc2lnbmVkDQo+IGNoYXIsIHNlcWFuOjpEbmFfPiwgc2VxYW46OkFsbG9jPHZvaWQ+ID4s DQo+IHNlcWFuOjpPd25lcjxzZXFhbjo6VGFnPHNlcWFuOjpEZWZhdWx0Xz4gPg0KPj4gLA0KPiB2 b2lkPihzZXFhbjo6SW5kZXg8c2VxYW46OlN0cmluZ1NldDxzZXFhbjo6U3RyaW5nPHNlcWFuOjpT aW1wbGVUeXBlPHVuc2lnbmVkDQo+IGNoYXIsIHNlcWFuOjpEbmFfPiwgc2VxYW46OkFsbG9jPHZv aWQ+ID4sDQo+IHNlcWFuOjpPd25lcjxzZXFhbjo6VGFnPHNlcWFuOjpEZWZhdWx0Xz4gPiA+LCBz ZXFhbjo6SW5kZXhFc2E8dm9pZD4gPiYpDQo+IChpbmRleF9lc2FfYmFzZS5oOg0KPiAzMDMpDQo+ ID09MTY2MTM9PSAgICBieSAweDlGOTY2REE6DQo+IHNlcWFuOjpJdGVyPHNlcWFuOjpJbmRleDxz ZXFhbjo6U3RyaW5nU2V0PHNlcWFuOjpTdHJpbmc8c2VxYW46OlNpbXBsZVR5cGU8dW5zaWduZWQN Cj4gY2hhciwgc2VxYW46OkRuYV8+LCBzZXFhbjo6QWxsb2M8dm9pZD4gPiwNCj4gc2VxYW46Ok93 bmVyPHNlcWFuOjpUYWc8c2VxYW46OkRlZmF1bHRfPiA+ID4sIHNlcWFuOjpJbmRleEVzDQo+IGE8 dm9pZD4gPiwgc2VxYW46OlZTVHJlZTxzZXFhbjo6VG9wRG93bjxzZXFhbjo6UHJlb3JkZXI+ID4N Cj4+IDo6SXRlcihzZXFhbjo6SW5kZXg8c2VxYW46OlN0cmluZ1NldDxzZXFhbjo6U3RyaW5nPHNl cWFuOjpTaW1wbGVUeXBlPHVuc2lnbmVkDQo+IGNoYXIsIHNlcWFuOjpEbmFfPiwgc2VxYW46OkFs bG9jPHZvaWQ+ID4sIHNlcWFuOjpPd25lcjxzZXFhbjo6VGFnPHNlcWFuOjpEDQo+IGVmYXVsdF8+ ID4gPiwgc2VxYW46OkluZGV4RXNhPHZvaWQ+ID4mKSAoaW5kZXhfZXNhX3N0cmVlLmg6MTMzKQ0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz ZXFhbi1kZXYgbWFpbGluZyBsaXN0DQo+IHNlcWFuLWRldkBsaXN0cy5mdS1iZXJsaW4uZGUNCj4g aHR0cHM6Ly9saXN0cy5mdS1iZXJsaW4uZGUvbGlzdGluZm8vc2VxYW4tZGV2DQoNCg== --_000_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBjbGFzcz0i Qm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+SGkgSm9obiw8YnI+DQo8YnI+DQp3ZSB1c2UgdmFs Z3JpbmQgaW4gb3VyIG5pZ2h0bHkgYnVpbGRzIHdpdGggZ2NjLTQuNiB1bmRlciBMaW51eCB3aXRo b3V0IGFueSBpc3N1ZXMgYW5kIHNvIGZhciBoYXZlbid0IHNlZW4gdGhhdCBlcnJvci4gRG8geW91 IGdldCB0aGUgc2FtZSBlcnJvciB3aXRoIG91ciB0ZXN0cywgZS5nLiB0ZXN0X2luZGV4X3N0cmVl X2l0ZXJhdG9ycyBvciB0ZXN0X2luZGV4X3JlcGVhdHM/PGJyPg0KPGJyPg0KSWYgbm90IGNvdWxk IHlvdSBwbGVhc2UgY3JlYXRlIGEgYnVnIHRpY2tldCB3aXRoIHNvbWUgc291cmNlcyBob3cgdG8g cmVwcm9kdWNlIHRoZSBlcnJvcj88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRGF2ZTxicj4NCjxi cj4NClBTOiBUaGlzIGlzIG91ciB2YWxncmluZCBzdXBwcmVzc2lvbiBmaWxlOjxicj4NCjxicj4N CjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPjxicj4NCi0tPGJyPg0KRGF2aWQgV2Vlc2UmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2Vlc2VAaW5mLmZ1 LWJlcmxpbi5kZTxicj4NCkZyZWllIFVuaXZlcnNpdMOkdCBCZXJsaW4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pbmYuZnUtYmVy bGluLmRlLyI+aHR0cDovL3d3dy5pbmYuZnUtYmVybGluLmRlLzwvYT48YnI+DQpJbnN0aXR1dCBm w7xyIEluZm9ybWF0aWsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUGhvbmU6ICYjNDM7NDkgMzAgODM4IDc1MTM3PGJyPg0KVGFrdXN0cmHDn2UgOSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbGdv cml0aG1pYyBCaW9pbmZvcm1hdGljczxicj4NCjE0MTk1IEJlcmxpbiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb29tIDAyMDxicj4NCjxi cj4NCkFtIDA2LjA2LjIwMTMgdW0gMTU6MzEgc2NocmllYiBKb2huIFJlaWQgJmx0O2oucmVpZEBt YWlsLmNyeXN0LmJiay5hYy51ayZndDs6PGJyPg0KPGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IElzIHZhbGdyaW5kIGEgdG9vbCB0aGF0IHBlb3BsZSB1c2Ugd2l0aCBTZXFB biBtdWNoPyBJcyBTZXFBbiBmcmVlIG9mIGFueTxicj4NCiZndDsgc3B1cmlvdXMgKG9yIG5vdCBz byBzcHVyaW91cykgbGVha3M/IERvZXMgYW55b25lIGhhdmUgYSB2YWxncmluZDxicj4NCiZndDsg c3VwcHJlc3Npb25zIGZpbGUgSSBtaWdodCBmaW5kIHVzZWZ1bCB3aXRoIGdjYy00LjY/IEZvciBp bnN0YW5jZSBJIGhhdmU8YnI+DQomZ3Q7IHRoZSBmb2xsb3dpbmcgcmVwb3J0ZWQgYnkgJnF1b3Q7 dmFsZ3JpbmQgLS1sZWFrLWNoZWNrPWZ1bGwmcXVvdDsgd2hlbiB1c2luZyBhPGJyPg0KJmd0OyBU b3BEb3duIGl0ZXJhdG9yIHdpdGggYW4gRVNBLiBJJ20gZ3Vlc3NpbmcgaXQgaXMgbm90IGEgcHJv YmxlbSBidXQgSSdkPGJyPg0KJmd0OyBsaWtlIHRvIHNlZSB3aGF0IG90aGVycyB0aGluay4gR2V0 dGluZyByaWQgb2YgYW55IHZhbGdyaW5kIHdhcm5pbmdzPGJyPg0KJmd0OyBnZW5lcmF0ZWQgYnkg U2VxQW4gd2lsbCBoZWxwIG1lIGxvY2F0ZSBhbnkgYnVncyBJIG1pZ2h0IGhhdmUgaW4gbXkgY29k ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGFnYWluIGZvciBhIGZhbnRhc3RpYyBsaWJy YXJ5LDxicj4NCiZndDsgSm9obi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPT0xNjYxMz09IE1lbWNo ZWNrLCBhIG1lbW9yeSBlcnJvciBkZXRlY3Rvcjxicj4NCiZndDsgPT0xNjYxMz09IENvcHlyaWdo dCAoQykgMjAwMi0yMDExLCBhbmQgR05VIEdQTCdkLCBieSBKdWxpYW4gU2V3YXJkIGV0IGFsLjxi cj4NCiZndDsgPT0xNjYxMz09IFVzaW5nIFZhbGdyaW5kLTMuNy4wIGFuZCBMaWJWRVg7IHJlcnVu IHdpdGggLWggZm9yIGNvcHlyaWdodCBpbmZvPGJyPg0KJmd0OyA9PTE2NjEzPT0gQ29tbWFuZDog L3Vzci9iaW4vcHl0aG9uIC91c3IvYmluL25vc2V0ZXN0cyAuLi9jYWN0by88YnI+DQomZ3Q7ID09 MTY2MTM9PTxicj4NCiZndDsgLi49PTE2NjEzPT0gQ29uZGl0aW9uYWwganVtcCBvciBtb3ZlIGRl cGVuZHMgb24gdW5pbml0aWFsaXNlZCB2YWx1ZShzKTxicj4NCiZndDsgPT0xNjYxMz09Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGF0IDB4OUZEMUU2Rjogdm9pZDxicj4NCiZndDsgc2VxYW46OmNyZWF0ZUNo aWxkdGFiJmx0O3NlcWFuOjpTdHJpbmcmbHQ7dW5zaWduZWQgbG9uZywgc2VxYW46OkFsbG9jJmx0 O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6U3RyaW5nJmx0O3Vuc2lnbmVkIGxvbmcs IHNlcWFuOjpBbGxvYyZsdDt2b2lkJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgKHNlcWFuOjpTdHJp bmcmbHQ7dW5zaWduZWQgbG9uZywgc2VxYW46OkFsbG9jJmx0O3ZvaWQmZ3Q7ICZndDsmYW1wOywg c2VxPGJyPg0KJmd0OyBhbjo6U3RyaW5nJmx0O3Vuc2lnbmVkIGxvbmcsIHNlcWFuOjpBbGxvYyZs dDt2b2lkJmd0OyAmZ3Q7IGNvbnN0JmFtcDspPGJyPg0KJmd0OyAoaW5kZXhfY2hpbGR0YWIuaDoy NjEpPGJyPg0KJmd0OyA9PTE2NjEzPT0mbmJzcDsmbmJzcDsmbmJzcDsgYnkgMHg5RkM2Mjc4OiBi b29sPGJyPg0KJmd0OyBzZXFhbjo6aW5kZXhDcmVhdGUmbHQ7c2VxYW46OlN0cmluZ1NldCZsdDtz ZXFhbjo6U3RyaW5nJmx0O3NlcWFuOjpTaW1wbGVUeXBlJmx0O3Vuc2lnbmVkPGJyPg0KJmd0OyBj aGFyLCBzZXFhbjo6RG5hXyZndDssIHNlcWFuOjpBbGxvYyZsdDt2b2lkJmd0OyAmZ3Q7LDxicj4N CiZndDsgc2VxYW46Ok93bmVyJmx0O3NlcWFuOjpUYWcmbHQ7c2VxYW46OkRlZmF1bHRfJmd0OyAm Z3Q7ICZndDssIHNlcWFuOjpJbmRleEVzYTxicj4NCiZndDsgJmx0O3ZvaWQmZ3Q7PGJyPg0KJmd0 OyZndDsgKHNlcWFuOjpJbmRleCZsdDtzZXFhbjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcm bHQ7c2VxYW46OlNpbXBsZVR5cGUmbHQ7dW5zaWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpE bmFfJmd0Oywgc2VxYW46OkFsbG9jJmx0O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6 T3duZXImbHQ7c2VxYW46OlRhZyZsdDtzZXFhbjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2Vx YW46OkluZGV4RXNhJmx0O3ZvaWQmZ3Q7ICZndDsmYW1wOyw8YnI+DQomZ3Q7IHNlcWFuOjpUYWcm bHQ7c2VxYW46Ojxicj4NCiZndDsgRmlicmVDaGlsZHRhYl8mZ3Q7LCBzZXFhbjo6Q2hpbGR0YWIp IChpbmRleF9zaGltcy5oOjYwOCk8YnI+DQomZ3Q7ID09MTY2MTM9PSZuYnNwOyZuYnNwOyZuYnNw OyBieSAweDlGQjkzNzM6IGJvb2w8YnI+DQomZ3Q7IHNlcWFuOjppbmRleENyZWF0ZSZsdDtzZXFh bjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcmbHQ7c2VxYW46OlNpbXBsZVR5cGUmbHQ7dW5z aWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpEbmFfJmd0Oywgc2VxYW46OkFsbG9jJmx0O3Zv aWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6T3duZXImbHQ7c2VxYW46OlRhZyZsdDtzZXFh bjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2VxYW46OkluZGV4RXNhPGJyPg0KJmd0OyAmbHQ7 dm9pZCZndDssPGJyPg0KJmd0OyBzZXFhbjo6RmlicmVDaGlsZHRhYl8mZ3Q7KHNlcWFuOjpJbmRl eCZsdDtzZXFhbjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcmbHQ7c2VxYW46OlNpbXBsZVR5 cGUmbHQ7dW5zaWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpEbmFfJmd0Oywgc2VxYW46OkFs bG9jJmx0O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6T3duZXImbHQ7c2VxYW46OlRh ZyZsdDtzZXFhbjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2VxYW46OkluZGV4RXNhJmx0O3Zv aWQmZ3Q7PGJyPg0KJmd0OyZndDsgJmFtcDssIHNlcWFuOjpUYWcmbHQ7c2VxYW46OkZpYnJlQ2hp bGR0YWJfJmd0OykgKGluZGV4X3NoaW1zLmg6NjE1KTxicj4NCiZndDsgPT0xNjYxMz09Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGJ5IDB4OUZBQ0NBMjogYm9vbDxicj4NCiZndDsgc2VxYW46OmluZGV4UmVx dWlyZSZsdDtzZXFhbjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcmbHQ7c2VxYW46OlNpbXBs ZVR5cGUmbHQ7dW5zaWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpEbmFfJmd0Oywgc2VxYW46 OkFsbG9jJmx0O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6T3duZXImbHQ7c2VxYW46 OlRhZyZsdDtzZXFhbjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2VxYW46OkluZGV4RXM8YnI+ DQomZ3Q7IGEmbHQ7dm9pZCZndDssPGJyPg0KJmd0OyBzZXFhbjo6RmlicmVDaGlsZHRhYl8mZ3Q7 KHNlcWFuOjpJbmRleCZsdDtzZXFhbjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcmbHQ7c2Vx YW46OlNpbXBsZVR5cGUmbHQ7dW5zaWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpEbmFfJmd0 Oywgc2VxYW46OkFsbG9jJmx0O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6T3duZXIm bHQ7c2VxYW46OlRhZyZsdDtzZXFhbjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2VxYW46Oklu ZGV4RXNhJmx0O3ZvaWQmZ3Q7PGJyPg0KJmd0OyZndDsgJmFtcDssIHNlcWFuOjpUYWcmbHQ7c2Vx YW46OkZpYnJlQ2hpbGR0YWJfJmd0OykgKGluZGV4X3NoaW1zLmg6NjY0KTxicj4NCiZndDsgPT0x NjYxMz09Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IDB4OUZBMEI5Mzogdm9pZDxicj4NCiZndDsgc2Vx YW46Ol9pbmRleFJlcXVpcmVUb3BEb3duSXRlcmF0aW9uJmx0O3NlcWFuOjpTdHJpbmdTZXQmbHQ7 c2VxYW46OlN0cmluZyZsdDtzZXFhbjo6U2ltcGxlVHlwZSZsdDt1bnNpZ25lZDxicj4NCiZndDsg Y2hhciwgc2VxYW46OkRuYV8mZ3Q7LCBzZXFhbjo6QWxsb2MmbHQ7dm9pZCZndDsgJmd0Oyw8YnI+ DQomZ3Q7IHNlcWFuOjpPd25lciZsdDtzZXFhbjo6VGFnJmx0O3NlcWFuOjpEZWZhdWx0XyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICw8YnI+DQomZ3Q7IHZvaWQmZ3Q7KHNlcWFuOjpJbmRleCZsdDtz ZXFhbjo6U3RyaW5nU2V0Jmx0O3NlcWFuOjpTdHJpbmcmbHQ7c2VxYW46OlNpbXBsZVR5cGUmbHQ7 dW5zaWduZWQ8YnI+DQomZ3Q7IGNoYXIsIHNlcWFuOjpEbmFfJmd0Oywgc2VxYW46OkFsbG9jJmx0 O3ZvaWQmZ3Q7ICZndDssPGJyPg0KJmd0OyBzZXFhbjo6T3duZXImbHQ7c2VxYW46OlRhZyZsdDtz ZXFhbjo6RGVmYXVsdF8mZ3Q7ICZndDsgJmd0Oywgc2VxYW46OkluZGV4RXNhJmx0O3ZvaWQmZ3Q7 ICZndDsmYW1wOyk8YnI+DQomZ3Q7IChpbmRleF9lc2FfYmFzZS5oOjxicj4NCiZndDsgMzAzKTxi cj4NCiZndDsgPT0xNjYxMz09Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IDB4OUY5NjZEQTo8YnI+DQom Z3Q7IHNlcWFuOjpJdGVyJmx0O3NlcWFuOjpJbmRleCZsdDtzZXFhbjo6U3RyaW5nU2V0Jmx0O3Nl cWFuOjpTdHJpbmcmbHQ7c2VxYW46OlNpbXBsZVR5cGUmbHQ7dW5zaWduZWQ8YnI+DQomZ3Q7IGNo YXIsIHNlcWFuOjpEbmFfJmd0Oywgc2VxYW46OkFsbG9jJmx0O3ZvaWQmZ3Q7ICZndDssPGJyPg0K Jmd0OyBzZXFhbjo6T3duZXImbHQ7c2VxYW46OlRhZyZsdDtzZXFhbjo6RGVmYXVsdF8mZ3Q7ICZn dDsgJmd0Oywgc2VxYW46OkluZGV4RXM8YnI+DQomZ3Q7IGEmbHQ7dm9pZCZndDsgJmd0Oywgc2Vx YW46OlZTVHJlZSZsdDtzZXFhbjo6VG9wRG93biZsdDtzZXFhbjo6UHJlb3JkZXImZ3Q7ICZndDs8 YnI+DQomZ3Q7Jmd0OyA6Okl0ZXIoc2VxYW46OkluZGV4Jmx0O3NlcWFuOjpTdHJpbmdTZXQmbHQ7 c2VxYW46OlN0cmluZyZsdDtzZXFhbjo6U2ltcGxlVHlwZSZsdDt1bnNpZ25lZDxicj4NCiZndDsg Y2hhciwgc2VxYW46OkRuYV8mZ3Q7LCBzZXFhbjo6QWxsb2MmbHQ7dm9pZCZndDsgJmd0Oywgc2Vx YW46Ok93bmVyJmx0O3NlcWFuOjpUYWcmbHQ7c2VxYW46OkQ8YnI+DQomZ3Q7IGVmYXVsdF8mZ3Q7 ICZndDsgJmd0Oywgc2VxYW46OkluZGV4RXNhJmx0O3ZvaWQmZ3Q7ICZndDsmYW1wOykgKGluZGV4 X2VzYV9zdHJlZS5oOjEzMyk8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNlcWFuLWRldiBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IHNlcWFuLWRldkBsaXN0cy5mdS1iZXJsaW4uZGU8YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vbGlzdHMuZnUtYmVybGluLmRlL2xpc3RpbmZvL3NlcWFuLWRldiI+aHR0 cHM6Ly9saXN0cy5mdS1iZXJsaW4uZGUvbGlzdGluZm8vc2VxYW4tZGV2PC9hPjxicj4NCjxicj4N CjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_-- --_004_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_ Content-Type: application/octet-stream; name="seqan.supp" Content-Description: seqan.supp Content-Disposition: attachment; filename="seqan.supp"; size=1278; creation-date="Fri, 07 Jun 2013 07:08:51 GMT"; modification-date="Fri, 07 Jun 2013 07:08:51 GMT" Content-ID: <50DBDAF5632D7D48AD599425190F3C47@campus.fu-berlin.de> Content-Transfer-Encoding: base64 IyBTdXBwcmVzcyBvdmVybGFwIHByb2JsZW1zIGluIFNUTCBwcmlvcml0eSBxdWV1ZSdzIHBvcCBm cm9tIFNlcWFuJ3MNCiMgdG9wb2xvZ2ljYWwgc29ydC4NCnsNCiAgIHN1cHBfc3RsX3ByaW9yaXR5 X3F1ZXVlX3BvcF9pZl9sZW5faXNfb25lDQogICBNZW1jaGVjazpPdmVybGFwDQogICBmdW46bWVt Y3B5DQogICBmdW46X1pTdDEwX19wb3BfaGVhcElOOV9fZ251X2N4eDE3X19ub3JtYWxfaXRlcmF0 b3JJUFN0NHBhaXJJbWpFU3Q2dmVjdG9ySVMzX1NhSVMzX0VFRUVTdDRsZXNzSVMzX0VFdlRfU0Jf U0JfVDBfDQogICBmdW46X1pTdDhwb3BfaGVhcElOOV9fZ251X2N4eDE3X19ub3JtYWxfaXRlcmF0 b3JJUFN0NHBhaXJJbWpFU3Q2dmVjdG9ySVMzX1NhSVMzX0VFRUVTdDRsZXNzSVMzX0VFdlRfU0Jf VDBfDQogICBmdW46X1pOU3QxNHByaW9yaXR5X3F1ZXVlSVN0NHBhaXJJbWpFU3Q2dmVjdG9ySVMx X1NhSVMxX0VFU3Q0bGVzc0lTMV9FRTNwb3BFdg0KICAgZnVuOl9aTjVzZXFhbjE1dG9wb2xvZ2lj YWxTb3J0Kg0KICAgLi4uDQogICBmdW46bWFpbg0KfQ0KDQojIFN1cHByZXNzICJzdGlsbCByZWFj aGFibGUiIG1lbW9yeSBmcm9tIGxpYmdvbXAsIHRoZSBsaWJyYXJ5IHdpdGggdGhlIHJ1bnRpbWUN CiMgZm9yIE9wZW5NUCBpbiBHQ0MuDQp7DQogICBzdXBwX2xpYmdvbXBfc2V0X251bV90aHJlYWRz DQogICBNZW1jaGVjazpMZWFrDQogICBmdW46bWFsbG9jDQogICBmdW46Z29tcF9tYWxsb2MNCiAg IGZ1bjpnb21wX25ld19pY3YNCiAgIC4uLg0KICAgZnVuOm1haW4NCn0NCnsNCiAgIHN1cHBfbGli Z29tcF90ZWFtX3N0YXJ0DQogICBNZW1jaGVjazpMZWFrDQogICBmdW46bWFsbG9jDQogICBmdW46 Z29tcF9tYWxsb2MNCiAgIGZ1bjpnb21wX3RlYW1fc3RhcnQNCiAgIC4uLg0KICAgZnVuOm1haW4N Cn0NCg0KIyBTdXBwcmVzcyB3YXJuaW5nIGluIHpsaWIuICBBbHNvIHNlZSB0aGUgemxpYiBGQVE6 DQojIGh0dHA6Ly93d3cuemxpYi5uZXQvemxpYl9mYXEuaHRtbCNmYXEzNg0Kew0KICAgc3VwcF96 bGliX2d6Y2xvc2UNCiAgIE1lbWNoZWNrOkNvbmQNCiAgIC4uLg0KICAgZnVuOmRlZmxhdGUNCiAg IGZ1bjpnemNsb3NlDQogICAuLi4NCiAgIGZ1bjptYWluDQp9DQp7DQogICBVbml0aWFsaXplZCBt ZW1vcnkgcmVhZCBpbiB6bGliJ3MgaW5mbGF0ZVJlc2V0MiAobm90IGEgcHJvYmxlbSkNCiAgIE1l bWNoZWNrOkNvbmQNCiAgIGZ1bjppbmZsYXRlUmVzZXQyDQogICBmdW46aW5mbGF0ZUluaXQyXw0K ICAgLi4uDQogICBmdW46bWFpbg0KfQ0K --_004_DCA4ABE82D5945E5A6F245452C4ED5F4fuberlinde_-- From weese@campus.fu-berlin.de Fri Jun 07 09:16:07 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqu5-001LDP-VU>; Fri, 07 Jun 2013 09:16:06 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqu5-000GcV-Tw>; Fri, 07 Jun 2013 09:16:05 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukqu5-0018HG-KN>; Fri, 07 Jun 2013 09:16:05 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 09:16:04 +0200 From: "Weese, David" To: SeqAn Development Thread-Topic: [Seqan-dev] razers3 memory problem Thread-Index: AQHOYdFZEdnW9PevTUG2rhdVn8H/7JkpuJQA Message-ID: <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> References: <51AF0867.3070509@molgen.mpg.de> In-Reply-To: <51AF0867.3070509@molgen.mpg.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5DF239F3D9FC1042B7B67D4E74578D91@campus.fu-berlin.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Fri, 07 Jun 2013 09:16:03 +0200 X-Original-Date: Fri, 7 Jun 2013 07:16:03 +0000 X-Originating-IP: 130.133.170.201 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370589365-0000097E-4254F85C/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000061, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-50.0 required=5.0 tests=ALL_TRUSTED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:16:07 -0000 Hi Matthias, RazerS keeps a q-gram index of reads in memory. Hence its memory consumptio= n is directly proportional to the input size. And it requires about 10GB fo= r 10M x 100bp reads. Unfortunately, there is currently no other option than= to split the input file into chunks and map then independently one-after-a= nother or in-parallel on a cluster. BAM outputs will certainly be supported in the near future and gzipped fast= q input could be supported but requires to benchmark the alternative I/O mo= dule before. Cheers, Dave -- David Weese weese@inf.fu-berlin.de Freie Universit=E4t Berlin http://www.inf.fu-berlin.de/ Institut f=FCr Informatik Phone: +49 30 838 75137 Takustra=DFe 9 Algorithmic Bioinformatics 14195 Berlin Room 020 Am 05.06.2013 um 11:44 schrieb Matthias Lienhard : > Hi, > when runnig razers3 on my paired end HiSeq fastq files I get the followin= g errors >=20 >=20 > razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq > terminate called recursively > terminate called recursively > Aborted >=20 > or >=20 > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted >=20 > It seems as memory usage is very high (>50gb). Each of the fastq files is= about 7 gb. When I take the first 100000 reads, the razers3 seems to work = fine. However, I don't want to split the files in small chucks and merge th= em together afterwards (because of disk usage and convenience - I have abou= t 50 samples to process) > Is there another way to handle this issue? >=20 > Also, it would be very convienient if gzipped fastq files could be used a= s input directly - and output in bam-format would be nice as well. >=20 > Best wishes, Matthias >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From jer15@hermes.cam.ac.uk Fri Jun 07 13:20:54 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukuiy-001rPK-SQ>; Fri, 07 Jun 2013 13:20:52 +0200 Received: from ppsw-mx-f.csi.cam.ac.uk ([131.111.8.149] helo=ppsw-42.csi.cam.ac.uk) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukuiy-002W3q-OL>; Fri, 07 Jun 2013 13:20:52 +0200 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from manaslu.utelisys.net ([217.117.239.6]:38445 helo=[192.168.108.41]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:jer15) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1Ukuix-00083E-7Q (Exim 4.80_167-5a66dd3) for seqan-dev@lists.fu-berlin.de (return-path ); Fri, 07 Jun 2013 12:20:51 +0100 Message-ID: <51B1C212.6090503@mail.cryst.bbk.ac.uk> Date: Fri, 07 Jun 2013 12:20:50 +0100 From: John Reid User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: SeqAn Development References: <51B08F4C.1000406@mail.cryst.bbk.ac.uk> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: "J.E. Reid" X-Originating-IP: 131.111.8.149 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370604052-0000097E-710D4B9B/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=1.1 required=5.0 tests=HTML_MESSAGE,MIME_HTML_ONLY X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: x Subject: Re: [Seqan-dev] SeqAn with valgrind X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 11:20:54 -0000 Dear Dave,

It is probably something I'm doing then. I'll have a look. Thanks for the suppression file.

John.

On 07/06/13 08:08, Weese, David wrote:

Hi John,

we use valgrind in our nightly builds with gcc-4.6 under Linux without any issues and so far haven't seen that error. Do you get the same error with our tests, e.g. test_index_stree_iterators or test_index_repeats?

If not could you please create a bug ticket with some sources how to reproduce the error?

Thanks,
Dave

PS: This is our valgrind suppression file:

--
David Weese                     weese@inf.fu-berlin.de
Freie Universität Berlin        http://www.inf.fu-berlin.de/
Institut für Informatik         Phone: +49 30 838 75137
Takustraße 9                    Algorithmic Bioinformatics
14195 Berlin                    Room 020

Am 06.06.2013 um 15:31 schrieb John Reid <j.reid@mail.cryst.bbk.ac.uk>:

> Hi all,
>
> Is valgrind a tool that people use with SeqAn much? Is SeqAn free of any
> spurious (or not so spurious) leaks? Does anyone have a valgrind
> suppressions file I might find useful with gcc-4.6? For instance I have
> the following reported by "valgrind --leak-check=full" when using a
> TopDown iterator with an ESA. I'm guessing it is not a problem but I'd
> like to see what others think. Getting rid of any valgrind warnings
> generated by SeqAn will help me locate any bugs I might have in my code.
>
> Thanks again for a fantastic library,
> John.
>
> ==16613== Memcheck, a memory error detector
> ==16613== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==16613== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==16613== Command: /usr/bin/python /usr/bin/nosetests ../cacto/
> ==16613==
> ..==16613== Conditional jump or move depends on uninitialised value(s)
> ==16613==    at 0x9FD1E6F: void
> seqan::createChildtab<seqan::String<unsigned long, seqan::Alloc<void> >,
> seqan::String<unsigned long, seqan::Alloc<void> >
>> (seqan::String<unsigned long, seqan::Alloc<void> >&, seq
> an::String<unsigned long, seqan::Alloc<void> > const&)
> (index_childtab.h:261)
> ==16613==    by 0x9FC6278: bool
> seqan::indexCreate<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa
> <void>
>> (seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa<void> >&,
> seqan::Tag<seqan::
> FibreChildtab_>, seqan::Childtab) (index_shims.h:608)
> ==16613==    by 0x9FB9373: bool
> seqan::indexCreate<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa
> <void>,
> seqan::FibreChildtab_>(seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa<void>
>> &, seqan::Tag<seqan::FibreChildtab_>) (index_shims.h:615)
> ==16613==    by 0x9FACCA2: bool
> seqan::indexRequire<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEs
> a<void>,
> seqan::FibreChildtab_>(seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa<void>
>> &, seqan::Tag<seqan::FibreChildtab_>) (index_shims.h:664)
> ==16613==    by 0x9FA0B93: void
> seqan::_indexRequireTopDownIteration<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> >
>> ,
> void>(seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEsa<void> >&)
> (index_esa_base.h:
> 303)
> ==16613==    by 0x9F966DA:
> seqan::Iter<seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >,
> seqan::Owner<seqan::Tag<seqan::Default_> > >, seqan::IndexEs
> a<void> >, seqan::VSTree<seqan::TopDown<seqan::Preorder> >
>> ::Iter(seqan::Index<seqan::StringSet<seqan::String<seqan::SimpleType<unsigned
> char, seqan::Dna_>, seqan::Alloc<void> >, seqan::Owner<seqan::Tag<seqan::D
> efault_> > >, seqan::IndexEsa<void> >&) (index_esa_stree.h:133)
>
> _______________________________________________
> seqan-dev mailing list
> seqan-dev@lists.fu-berlin.de
> https://lists.fu-berlin.de/listinfo/seqan-dev
_______________________________________________
seqan-dev mailing list
seqan-dev@lists.fu-berlin.de
https://lists.fu-berlin.de/listinfo/seqan-dev

From lienhard@molgen.mpg.de Fri Jun 07 14:52:04 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukw9B-0024W7-E2>; Fri, 07 Jun 2013 14:52:01 +0200 Received: from mx1.molgen.mpg.de ([141.14.16.9]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukw9B-002oeA-CQ>; Fri, 07 Jun 2013 14:52:01 +0200 Received: from agrajag.molgen.mpg.de (agrajag.molgen.mpg.de [141.14.24.233]) by mx.molgen.mpg.de (Postfix) with ESMTP id 4976B8001FB62 for ; Fri, 7 Jun 2013 14:52:00 +0200 (CEST) Message-ID: <51B1D770.406@molgen.mpg.de> Date: Fri, 07 Jun 2013 14:52:00 +0200 From: Matthias Lienhard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130506 Thunderbird/17.0.5 MIME-Version: 1.0 To: SeqAn Development References: <51AF0867.3070509@molgen.mpg.de> <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> In-Reply-To: <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 141.14.16.9 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370609521-0000097E-08E8B35B/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:52:04 -0000 Hi Dave, I see. Is it planned, that the reads are processed in blocks internally? 10M reads is not really a realistic input size these days, and I imagine, a lot of potential users are scared off, when the program (or worse: the server) crashes. Also, it is not really a practical solution to split the files, as handling the data is difficult enough. Best, Matthias On 06/07/13 09:16, Weese, David wrote: > Hi Matthias, > > RazerS keeps a q-gram index of reads in memory. Hence its memory consumption is directly proportional to the input size. And it requires about 10GB for 10M x 100bp reads. Unfortunately, there is currently no other option than to split the input file into chunks and map then independently one-after-another or in-parallel on a cluster. > > BAM outputs will certainly be supported in the near future and gzipped fastq input could be supported but requires to benchmark the alternative I/O module before. > > Cheers, > Dave > > -- > David Weese weese@inf.fu-berlin.de > Freie Universit�t Berlin http://www.inf.fu-berlin.de/ > Institut f�r Informatik Phone: +49 30 838 75137 > Takustra�e 9 Algorithmic Bioinformatics > 14195 Berlin Room 020 > > Am 05.06.2013 um 11:44 schrieb Matthias Lienhard : > >> Hi, >> when runnig razers3 on my paired end HiSeq fastq files I get the following errors >> >> >> razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq >> terminate called recursively >> terminate called recursively >> Aborted >> >> or >> >> terminate called after throwing an instance of 'std::bad_alloc' >> what(): std::bad_alloc >> Aborted >> >> It seems as memory usage is very high (>50gb). Each of the fastq files is about 7 gb. When I take the first 100000 reads, the razers3 seems to work fine. However, I don't want to split the files in small chucks and merge them together afterwards (because of disk usage and convenience - I have about 50 samples to process) >> Is there another way to handle this issue? >> >> Also, it would be very convienient if gzipped fastq files could be used as input directly - and output in bam-format would be nice as well. >> >> Best wishes, Matthias >> >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From Enrico.Siragusa@fu-berlin.de Fri Jun 07 15:29:58 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukwjs-002ACJ-VO>; Fri, 07 Jun 2013 15:29:57 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukwjs-003QqZ-Tu>; Fri, 07 Jun 2013 15:29:56 +0200 Received: from cas2.campus.fu-berlin.de ([130.133.170.202]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukwjs-00236B-K4>; Fri, 07 Jun 2013 15:29:56 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS2.campus.fu-berlin.de ([130.133.170.202]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 15:29:55 +0200 From: "Siragusa, Enrico" To: SeqAn Development Thread-Topic: [Seqan-dev] razers3 memory problem Thread-Index: AQHOYdFHPW785mBHOkqLNHOyWZUp25kpuJOAgABd3QCAAAqVgA== Message-ID: <875C27B2-9D03-49F6-9CFE-F4CCA689E066@fu-berlin.de> References: <51AF0867.3070509@molgen.mpg.de> <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> <51B1D770.406@molgen.mpg.de> In-Reply-To: <51B1D770.406@molgen.mpg.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: <4CE988D046D20E4C8A42849F77F8C4EB@campus.fu-berlin.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Fri, 07 Jun 2013 15:29:54 +0200 X-Original-Date: Fri, 7 Jun 2013 13:29:54 +0000 X-Originating-IP: 130.133.170.202 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1370611796-0000097E-1200509E/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-50.0 required=5.0 tests=ALL_TRUSTED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:29:58 -0000 Hi Matthias, If you don't need strict 100% sensitivity, then you could try out Masai. Th= ere is an option to select how many reads the program should map at once, e= .g. with "--mapping-block 1000000" the program would load only 1M reads at = time. Btw Masai gets faster with more reads, so I advise you to map at leas= t 10M reads. Mapping 10M reads on human requires 19GB of memory. If you don't dispose of= so much memory, then you could use the FM-index. You need to pass the opti= on "--index fm" to indexer/mapper apps. In this way you should be able to r= un a mapping job within 9GB of memory. If 9GB of memory is still too much, = you can disable multiple backtracking, but the mapper wouldn't take less th= an ~7GB of memory=85 Enrico On Jun 7, 2013, at 2:52 PM, Matthias Lienhard wrot= e: > Hi Dave, >=20 > I see. Is it planned, that the reads are processed in blocks internally? = 10M reads is not really a realistic input size these days, and I imagine, a= lot of potential users are scared off, when the program (or worse: the ser= ver) crashes. > Also, it is not really a practical solution to split the files, as handli= ng the data is difficult enough. >=20 > Best, Matthias >=20 > On 06/07/13 09:16, Weese, David wrote: >> Hi Matthias, >>=20 >> RazerS keeps a q-gram index of reads in memory. Hence its memory consump= tion is directly proportional to the input size. And it requires about 10GB= for 10M x 100bp reads. Unfortunately, there is currently no other option t= han to split the input file into chunks and map then independently one-afte= r-another or in-parallel on a cluster. >>=20 >> BAM outputs will certainly be supported in the near future and gzipped f= astq input could be supported but requires to benchmark the alternative I/O= module before. >>=20 >> Cheers, >> Dave >>=20 >> -- >> David Weese weese@inf.fu-berlin.de >> Freie Universit=E4t Berlin http://www.inf.fu-berlin.de/ >> Institut f=FCr Informatik Phone: +49 30 838 75137 >> Takustra=DFe 9 Algorithmic Bioinformatics >> 14195 Berlin Room 020 >>=20 >> Am 05.06.2013 um 11:44 schrieb Matthias Lienhard : >>=20 >>> Hi, >>> when runnig razers3 on my paired end HiSeq fastq files I get the follow= ing errors >>>=20 >>>=20 >>> razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq >>> terminate called recursively >>> terminate called recursively >>> Aborted >>>=20 >>> or >>>=20 >>> terminate called after throwing an instance of 'std::bad_alloc' >>> what(): std::bad_alloc >>> Aborted >>>=20 >>> It seems as memory usage is very high (>50gb). Each of the fastq files = is about 7 gb. When I take the first 100000 reads, the razers3 seems to wor= k fine. However, I don't want to split the files in small chucks and merge = them together afterwards (because of disk usage and convenience - I have ab= out 50 samples to process) >>> Is there another way to handle this issue? >>>=20 >>> Also, it would be very convienient if gzipped fastq files could be used= as input directly - and output in bam-format would be nice as well. >>>=20 >>> Best wishes, Matthias >>>=20 >>> _______________________________________________ >>> seqan-dev mailing list >>> seqan-dev@lists.fu-berlin.de >>> https://lists.fu-berlin.de/listinfo/seqan-dev >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From lienhard@molgen.mpg.de Fri Jun 07 15:36:35 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkwqH-002BZR-D1>; Fri, 07 Jun 2013 15:36:33 +0200 Received: from mx1.molgen.mpg.de ([141.14.16.9]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UkwqH-0030FP-A5>; Fri, 07 Jun 2013 15:36:33 +0200 Received: from agrajag.molgen.mpg.de (agrajag.molgen.mpg.de [141.14.24.233]) by mx.molgen.mpg.de (Postfix) with ESMTP id CC0448001FB60 for ; Fri, 7 Jun 2013 15:36:31 +0200 (CEST) Message-ID: <51B1E1DF.2000402@molgen.mpg.de> Date: Fri, 07 Jun 2013 15:36:31 +0200 From: Matthias Lienhard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130506 Thunderbird/17.0.5 MIME-Version: 1.0 To: SeqAn Development References: <51AF0867.3070509@molgen.mpg.de> <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> <51B1D770.406@molgen.mpg.de> <875C27B2-9D03-49F6-9CFE-F4CCA689E066@fu-berlin.de> In-Reply-To: <875C27B2-9D03-49F6-9CFE-F4CCA689E066@fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 141.14.16.9 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1370612193-0000097E-F3025AFF/3897699368-0/0-1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=1.0 required=5.0 tests=FU_XPURGATE_SUSP, RCVD_IN_DNSWL_NONE X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Burundi.ZEDAT.FU-Berlin.DE X-Spam-Level: x Subject: Re: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:36:35 -0000 Hi Enrico, does Masai support multithreading (without splitting the input files) by now? 20 gb memory (or more) is no problem. Best, Matthias On 06/07/13 15:29, Siragusa, Enrico wrote: > Hi Matthias, > > If you don't need strict 100% sensitivity, then you could try out Masai. There is an option to select how many reads the program should map at once, e.g. with "--mapping-block 1000000" the program would load only 1M reads at time. Btw Masai gets faster with more reads, so I advise you to map at least 10M reads. > > Mapping 10M reads on human requires 19GB of memory. If you don't dispose of so much memory, then you could use the FM-index. You need to pass the option "--index fm" to indexer/mapper apps. In this way you should be able to run a mapping job within 9GB of memory. If 9GB of memory is still too much, you can disable multiple backtracking, but the mapper wouldn't take less than ~7GB of memory� > > Enrico > > On Jun 7, 2013, at 2:52 PM, Matthias Lienhard wrote: > >> Hi Dave, >> >> I see. Is it planned, that the reads are processed in blocks internally? 10M reads is not really a realistic input size these days, and I imagine, a lot of potential users are scared off, when the program (or worse: the server) crashes. >> Also, it is not really a practical solution to split the files, as handling the data is difficult enough. >> >> Best, Matthias >> >> On 06/07/13 09:16, Weese, David wrote: >>> Hi Matthias, >>> >>> RazerS keeps a q-gram index of reads in memory. Hence its memory consumption is directly proportional to the input size. And it requires about 10GB for 10M x 100bp reads. Unfortunately, there is currently no other option than to split the input file into chunks and map then independently one-after-another or in-parallel on a cluster. >>> >>> BAM outputs will certainly be supported in the near future and gzipped fastq input could be supported but requires to benchmark the alternative I/O module before. >>> >>> Cheers, >>> Dave >>> >>> -- >>> David Weese weese@inf.fu-berlin.de >>> Freie Universit�t Berlin http://www.inf.fu-berlin.de/ >>> Institut f�r Informatik Phone: +49 30 838 75137 >>> Takustra�e 9 Algorithmic Bioinformatics >>> 14195 Berlin Room 020 >>> >>> Am 05.06.2013 um 11:44 schrieb Matthias Lienhard : >>> >>>> Hi, >>>> when runnig razers3 on my paired end HiSeq fastq files I get the following errors >>>> >>>> >>>> razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq >>>> terminate called recursively >>>> terminate called recursively >>>> Aborted >>>> >>>> or >>>> >>>> terminate called after throwing an instance of 'std::bad_alloc' >>>> what(): std::bad_alloc >>>> Aborted >>>> >>>> It seems as memory usage is very high (>50gb). Each of the fastq files is about 7 gb. When I take the first 100000 reads, the razers3 seems to work fine. However, I don't want to split the files in small chucks and merge them together afterwards (because of disk usage and convenience - I have about 50 samples to process) >>>> Is there another way to handle this issue? >>>> >>>> Also, it would be very convienient if gzipped fastq files could be used as input directly - and output in bam-format would be nice as well. >>>> >>>> Best wishes, Matthias >>>> >>>> _______________________________________________ >>>> seqan-dev mailing list >>>> seqan-dev@lists.fu-berlin.de >>>> https://lists.fu-berlin.de/listinfo/seqan-dev >>> _______________________________________________ >>> seqan-dev mailing list >>> seqan-dev@lists.fu-berlin.de >>> https://lists.fu-berlin.de/listinfo/seqan-dev >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From Enrico.Siragusa@fu-berlin.de Fri Jun 07 15:56:11 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukx9F-002EPc-LD>; Fri, 07 Jun 2013 15:56:09 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukx9F-003gkh-K6>; Fri, 07 Jun 2013 15:56:09 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ukx9F-00276P-Br>; Fri, 07 Jun 2013 15:56:09 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Fri, 7 Jun 2013 15:56:08 +0200 From: "Siragusa, Enrico" To: SeqAn Development Thread-Topic: [Seqan-dev] razers3 memory problem Thread-Index: AQHOYdFHPW785mBHOkqLNHOyWZUp25kpuJOAgABd3QCAAAqVgIAAAduAgAAFeAA= Message-ID: References: <51AF0867.3070509@molgen.mpg.de> <994257E5-A8C4-4B30-A3AC-C56893537CAB@fu-berlin.de> <51B1D770.406@molgen.mpg.de> <875C27B2-9D03-49F6-9CFE-F4CCA689E066@fu-berlin.de> <51B1E1DF.2000402@molgen.mpg.de> In-Reply-To: <51B1E1DF.2000402@molgen.mpg.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: <04E9BD3E2414804FA0A842553A99F57E@campus.fu-berlin.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Fri, 07 Jun 2013 15:56:07 +0200 X-Original-Date: Fri, 7 Jun 2013 13:56:07 +0000 X-Originating-IP: 130.133.170.201 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1370613369-0000097E-339A19A8/3897699368-0/0-1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-49.0 required=5.0 tests=ALL_TRUSTED, FU_XPURGATE_SUSP X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Dschibuti.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] razers3 memory problem X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:56:11 -0000 Oh, I just noticed that you are mapping paired-end data! Then I wouldn't su= ggest you Masai because it wouldn't be as fast as on single-end data and, w= orse than that, you could potentially get wrong results as it hasn't been u= sed that much on paired-end data... On Jun 7, 2013, at 3:36 PM, Matthias Lienhard wrote: > Hi Enrico, >=20 > does Masai support multithreading (without splitting the input files) by = now? 20 gb memory (or more) is no problem. >=20 > Best, Matthias >=20 > On 06/07/13 15:29, Siragusa, Enrico wrote: >> Hi Matthias, >>=20 >> If you don't need strict 100% sensitivity, then you could try out Masai.= There is an option to select how many reads the program should map at once= , e.g. with "--mapping-block 1000000" the program would load only 1M reads = at time. Btw Masai gets faster with more reads, so I advise you to map at l= east 10M reads. >>=20 >> Mapping 10M reads on human requires 19GB of memory. If you don't dispose= of so much memory, then you could use the FM-index. You need to pass the o= ption "--index fm" to indexer/mapper apps. In this way you should be able t= o run a mapping job within 9GB of memory. If 9GB of memory is still too muc= h, you can disable multiple backtracking, but the mapper wouldn't take less= than ~7GB of memory=85 >>=20 >> Enrico >>=20 >> On Jun 7, 2013, at 2:52 PM, Matthias Lienhard w= rote: >>=20 >>> Hi Dave, >>>=20 >>> I see. Is it planned, that the reads are processed in blocks internally= ? 10M reads is not really a realistic input size these days, and I imagine,= a lot of potential users are scared off, when the program (or worse: the s= erver) crashes. >>> Also, it is not really a practical solution to split the files, as hand= ling the data is difficult enough. >>>=20 >>> Best, Matthias >>>=20 >>> On 06/07/13 09:16, Weese, David wrote: >>>> Hi Matthias, >>>>=20 >>>> RazerS keeps a q-gram index of reads in memory. Hence its memory consu= mption is directly proportional to the input size. And it requires about 10= GB for 10M x 100bp reads. Unfortunately, there is currently no other option= than to split the input file into chunks and map then independently one-af= ter-another or in-parallel on a cluster. >>>>=20 >>>> BAM outputs will certainly be supported in the near future and gzipped= fastq input could be supported but requires to benchmark the alternative I= /O module before. >>>>=20 >>>> Cheers, >>>> Dave >>>>=20 >>>> -- >>>> David Weese weese@inf.fu-berlin.de >>>> Freie Universit=E4t Berlin http://www.inf.fu-berlin.de/ >>>> Institut f=FCr Informatik Phone: +49 30 838 75137 >>>> Takustra=DFe 9 Algorithmic Bioinformatics >>>> 14195 Berlin Room 020 >>>>=20 >>>> Am 05.06.2013 um 11:44 schrieb Matthias Lienhard : >>>>=20 >>>>> Hi, >>>>> when runnig razers3 on my paired end HiSeq fastq files I get the foll= owing errors >>>>>=20 >>>>>=20 >>>>> razers3 -i 94 -rr 95 -tc 20 -o sample.sam reads1.fastq reads2.fastq >>>>> terminate called recursively >>>>> terminate called recursively >>>>> Aborted >>>>>=20 >>>>> or >>>>>=20 >>>>> terminate called after throwing an instance of 'std::bad_alloc' >>>>> what(): std::bad_alloc >>>>> Aborted >>>>>=20 >>>>> It seems as memory usage is very high (>50gb). Each of the fastq file= s is about 7 gb. When I take the first 100000 reads, the razers3 seems to w= ork fine. However, I don't want to split the files in small chucks and merg= e them together afterwards (because of disk usage and convenience - I have = about 50 samples to process) >>>>> Is there another way to handle this issue? >>>>>=20 >>>>> Also, it would be very convienient if gzipped fastq files could be us= ed as input directly - and output in bam-format would be nice as well. >>>>>=20 >>>>> Best wishes, Matthias >>>>>=20 >>>>> _______________________________________________ >>>>> seqan-dev mailing list >>>>> seqan-dev@lists.fu-berlin.de >>>>> https://lists.fu-berlin.de/listinfo/seqan-dev >>>> _______________________________________________ >>>> seqan-dev mailing list >>>> seqan-dev@lists.fu-berlin.de >>>> https://lists.fu-berlin.de/listinfo/seqan-dev >>> _______________________________________________ >>> seqan-dev mailing list >>> seqan-dev@lists.fu-berlin.de >>> https://lists.fu-berlin.de/listinfo/seqan-dev >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From jer15@hermes.cam.ac.uk Wed Jun 12 07:29:15 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UmdcP-000W4w-Md>; Wed, 12 Jun 2013 07:29:13 +0200 Received: from ppsw-33.csi.cam.ac.uk ([131.111.8.133]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UmdcP-0027Ay-K1>; Wed, 12 Jun 2013 07:29:13 +0200 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from manaslu.utelisys.net ([217.117.239.6]:49827 helo=[192.168.109.98]) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:jer15) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UmdcO-0002PH-gY (Exim 4.80_167-5a66dd3) for seqan-dev@lists.fu-berlin.de (return-path ); Wed, 12 Jun 2013 06:29:12 +0100 Message-ID: <51B80727.6090808@mail.cryst.bbk.ac.uk> Date: Wed, 12 Jun 2013 06:29:11 +0100 From: John Reid User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: SeqAn Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: "J.E. Reid" X-Originating-IP: 131.111.8.133 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1371014953-0000097E-3A24463A/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.012675, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] Empty index crashes X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 05:29:15 -0000 Hi, Using an empty Index crashes. Should I really have to check if there is some text in a StringSet before building the index or is it a bug? This code: #include int main( int argc, char * argv[] ) { using namespace seqan; typedef StringSet< String< Dna5 > > string_set_t; typedef Index< string_set_t > index_t; string_set_t seqs; index_t index( seqs ); Iterator< index_t, TopDown<> >::Type iterator( index ); return 0; } gives the following for a debug build: .... core/include/seqan/sequence/string_base.h:461 Assertion failed : static_cast(pos) < static_cast(length(me)) was: 0 >= 0 (Trying to access an element behind the last one!) Aborted (core dumped) I'm using svn version 14052 Regards, John. From wandelt@informatik.hu-berlin.de Thu Jun 13 10:02:07 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Un2Tu-003SRq-Je>; Thu, 13 Jun 2013 10:02:06 +0200 Received: from mail.informatik.hu-berlin.de ([141.20.20.50]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Un2Tu-002Fcx-Hy>; Thu, 13 Jun 2013 10:02:06 +0200 Received: from mailbox.informatik.hu-berlin.de (mailbox.informatik.hu-berlin.de [141.20.20.63]) by mail.informatik.hu-berlin.de (8.14.2+Sun/8.14.2/INF-2.0-MA-SOLARIS-2.10-25) with ESMTP id r5D825BH006742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Jun 2013 10:02:05 +0200 (CEST) Received: from localhost.localdomain (g225126049.adsl.alicedsl.de [92.225.126.49]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.14.2+Sun/8.14.2/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTP id r5D8247N013502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jun 2013 10:02:04 +0200 (CEST) Message-ID: <51B97C08.2050209@informatik.hu-berlin.de> Date: Thu, 13 Jun 2013 10:00:08 +0200 From: Sebastian Wandelt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: seqan-dev@lists.fu-berlin.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.3 at mailbox X-Virus-Status: Clean X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.2.7 (mail.informatik.hu-berlin.de [141.20.20.50]); Thu, 13 Jun 2013 10:02:05 +0200 (CEST) X-Originating-IP: 141.20.20.50 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1371110526-0000097E-7CB1FE21/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.494004, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Algerien.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] IndexEsa and longest prefix search (single step of greedy LZW decomposition) X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:02:08 -0000 Hi, I would like to use IndexEsa to find the longest infix which is a prefix of another (not indexed) string. This step is part of an algorithm to compute a greedy LZW-decomposition of a string with respect to a reference string. Example: Given an IndexEsa over AAAACCCCGGGGTTTT, I would like to have the longest prefix of CCCGGGAAAT, occurring as an infix in AAAACCCCGGGGTTTT. The result should be position 5 (and length 6), since the prefix CCCGGG can be found at position 5 (0-based string access) and is of length 6. Is there any ready code for solving this problem in Seqan? I think this should be a standard-operation for suffix trees. I haven't found any code that can be used directly, although I think that TopDown-Iterators might be the thing to go for. Thanks, Sebastian From weese@campus.fu-berlin.de Thu Jun 13 14:24:32 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Un6Zq-003vWA-Sj>; Thu, 13 Jun 2013 14:24:30 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Un6Zq-002bdm-RC>; Thu, 13 Jun 2013 14:24:30 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Un6Zq-000C6k-EM>; Thu, 13 Jun 2013 14:24:30 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 14:24:29 +0200 From: "Weese, David" To: SeqAn Development Thread-Topic: [Seqan-dev] IndexEsa and longest prefix search (single step of greedy LZW decomposition) Thread-Index: AQHOaAxzJ0fNPVN7rky1ZgxfaSTuPpkzcEUA Message-ID: <7D9D2058-2E30-4ADC-90D5-A90A1B06C8C0@fu-berlin.de> References: <51B97C08.2050209@informatik.hu-berlin.de> In-Reply-To: <51B97C08.2050209@informatik.hu-berlin.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Thu, 13 Jun 2013 14:24:28 +0200 X-Original-Date: Thu, 13 Jun 2013 12:24:28 +0000 X-Originating-IP: 130.133.170.201 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1371126270-0000097E-5845859B/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.291729, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-50.0 required=5.0 tests=ALL_TRUSTED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] IndexEsa and longest prefix search (single step of greedy LZW decomposition) X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:24:32 -0000 Hi Sebastian, sounds like you want to do a simple prefix search of a pattern. That can be= done with a top-down iterator, say iter, (that starts in the root node) wh= ich you move down along your not-indexed string with goDown(iter, "CCCGGGAA= AT"); After that it stops in the node that still is a substring of the text= , i.e. the longest prefix. To get the occurrences or length of it use getOccurrences(iter) or repLengt= h(iter) Cheers, David -- David Weese weese@inf.fu-berlin.de Freie Universit=E4t Berlin http://www.inf.fu-berlin.de/ Institut f=FCr Informatik Phone: +49 30 838 75137 Takustra=DFe 9 Algorithmic Bioinformatics 14195 Berlin Room 020 Am 13.06.2013 um 10:00 schrieb Sebastian Wandelt : > Hi, >=20 > I would like to use IndexEsa to find the longest infix which is a prefix = of another (not indexed) string. > This step is part of an algorithm to compute a greedy LZW-decomposition o= f a string with respect to a reference string. >=20 > Example: >=20 > Given an IndexEsa over AAAACCCCGGGGTTTT, I would like to have the longest= prefix of CCCGGGAAAT, occurring as an infix in AAAACCCCGGGGTTTT. > The result should be position 5 (and length 6), since the prefix CCCGGG c= an be found at position 5 (0-based string access) and is of length 6. >=20 > Is there any ready code for solving this problem in Seqan? I think this s= hould be a standard-operation for suffix trees. > I haven't found any code that can be used directly, although I think that= TopDown-Iterators might be the thing to go for. >=20 > Thanks, > Sebastian >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From wandelt@informatik.hu-berlin.de Sat Jun 15 07:45:26 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UnjIi-003mI7-R9>; Sat, 15 Jun 2013 07:45:24 +0200 Received: from mail.informatik.hu-berlin.de ([141.20.20.50]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UnjIi-0014ZA-PO>; Sat, 15 Jun 2013 07:45:24 +0200 Received: from mailbox.informatik.hu-berlin.de (mailbox.informatik.hu-berlin.de [141.20.20.63]) by mail.informatik.hu-berlin.de (8.14.2+Sun/8.14.2/INF-2.0-MA-SOLARIS-2.10-25) with ESMTP id r5F5jNA7002389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 15 Jun 2013 07:45:23 +0200 (CEST) Received: from localhost.localdomain (g225125011.adsl.alicedsl.de [92.225.125.11]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.14.2+Sun/8.14.2/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTP id r5F5jMGx007744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Jun 2013 07:45:22 +0200 (CEST) Message-ID: <51BBFEFD.1030906@informatik.hu-berlin.de> Date: Sat, 15 Jun 2013 07:43:25 +0200 From: Sebastian Wandelt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: seqan-dev@lists.fu-berlin.de References: <51B97C08.2050209@informatik.hu-berlin.de> <7D9D2058-2E30-4ADC-90D5-A90A1B06C8C0@fu-berlin.de> In-Reply-To: <7D9D2058-2E30-4ADC-90D5-A90A1B06C8C0@fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.3 at mailbox X-Virus-Status: Clean X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.2.7 (mail.informatik.hu-berlin.de [141.20.20.50]); Sat, 15 Jun 2013 07:45:23 +0200 (CEST) X-Originating-IP: 141.20.20.50 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1371275124-0000097E-E81971F4/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.073746, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat9255cc3 on Dschibuti.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] IndexEsa and longest prefix search (single step of greedy LZW decomposition) X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 05:45:26 -0000 Hi David, thank you for your help. The keywords you mentioned helped me to solve my small puzzle :-) Here is a short code snippet (in case anybody else encounters a similar problem): typedef seqan::TopDown > TIterSpec; typedef seqan::Index, seqan::IndexEsa > TIndex; typedef seqan::Iter > TIter; string rawstring="TESTERTES"; TIndex index_esa(rawstring); TIter myit(index_esa); seqan::goDown(myit, "TESA"); seqan::String< seqan::SAValue::Type > occs=seqan::getOccurrences(myit); seqan::orderOccurrences(occs); for(unsigned i = 0; i < seqan::length(occs); i++) { cout< Hi Sebastian, > > sounds like you want to do a simple prefix search of a pattern. That can be done with a top-down iterator, say iter, (that starts in the root node) which you move down along your not-indexed string with goDown(iter, "CCCGGGAAAT"); After that it stops in the node that still is a substring of the text, i.e. the longest prefix. > To get the occurrences or length of it use getOccurrences(iter) or repLength(iter) > > Cheers, > David > > -- > David Weese weese@inf.fu-berlin.de > Freie Universit�t Berlin http://www.inf.fu-berlin.de/ > Institut f�r Informatik Phone: +49 30 838 75137 > Takustra�e 9 Algorithmic Bioinformatics > 14195 Berlin Room 020 > > Am 13.06.2013 um 10:00 schrieb Sebastian Wandelt : > >> Hi, >> >> I would like to use IndexEsa to find the longest infix which is a prefix of another (not indexed) string. >> This step is part of an algorithm to compute a greedy LZW-decomposition of a string with respect to a reference string. >> >> Example: >> >> Given an IndexEsa over AAAACCCCGGGGTTTT, I would like to have the longest prefix of CCCGGGAAAT, occurring as an infix in AAAACCCCGGGGTTTT. >> The result should be position 5 (and length 6), since the prefix CCCGGG can be found at position 5 (0-based string access) and is of length 6. >> >> Is there any ready code for solving this problem in Seqan? I think this should be a standard-operation for suffix trees. >> I haven't found any code that can be used directly, although I think that TopDown-Iterators might be the thing to go for. >> >> Thanks, >> Sebastian >> >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From nomi.meixner@student.uni-tuebingen.de Mon Jun 24 18:40:04 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ur9oA-001Ort-UB>; Mon, 24 Jun 2013 18:40:03 +0200 Received: from mx09.uni-tuebingen.de ([134.2.3.2]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ur9oA-001GJk-RA>; Mon, 24 Jun 2013 18:40:02 +0200 Received: from kagou.localnet (kagou.am10.uni-tuebingen.de [134.2.182.82]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id r5OGe0Mh019341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Jun 2013 18:40:00 +0200 From: Nomi Meixner To: SeqAn Mailing list Date: Mon, 24 Jun 2013 18:39:59 +0200 Message-ID: <3003921.rOCDlF5gvM@kagou> User-Agent: KMail/4.10.4 (Linux/3.9.6-200.fc18.i686; KDE/4.10.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.26; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.2.12.66; VDF: 7.11.86.182; host: mx09); id=2539-lxmGQ9 X-Originating-IP: 134.2.3.2 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1372092002-0000097E-CCB9F9DD/0-11087279796/0-2 X-Bogosity: Ham, tests=bogofilter, spamicity=0.013283, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-1.3 required=5.0 tests=FU_XPURGATE_SUSP, RCVD_IN_DNSWL_MED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Dschibuti.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] SeqAn installation with manually compiled boost library X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:40:04 -0000 Hello everyone, I have trouble installing SeqAn on a RHEL system, where I installed the= zlib and boost libraries manually. My folder structure looks the following: {TARGET_DIR}/bin -> preferred build directory {TARGET_DIR}/doc {TARGET_DIR}/include/boost/ -> contains all the boost subfolders .hpp f= iles etc. {TARGET_DIR}/lib -> contains libboost* and libz* {TARGET_DIR}/seqan-trunk -> as checked out from SVN {TARGET_DIR}/share Following the tutorial (trac.seqan.de/wiki/Tutorial/GettingStarted/Linu= xMakefiles), from the {TARGET_DIR}/bin folder I call cmake ../seqan-tru= nk -DCMAKE_BUILD_TYPE=3DRelease, which succeeds. Then >make Make fails at approximately 5% having trouble to find the boost math li= braries while installing snp_store. The (potentially crucial part of the) environment looks like this: {TARGET_DIR}/bin$ env | grep CMAKE CMAKE_MAN_DIR=3D/opt/.../.../cmake/2.8.6/man CMAKE_DOC_DIR=3D/opt/.../.../cmake/2.8.6/doc CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib CMAKE_BIN_DIR=3D/opt/.../.../cmake/2.8.6/bin CMAKE_HOME=3D/opt/.../.../cmake/2.8.6 DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include CMAKE_VERSION=3D2.8.6 CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include {TARGET_DIR}/bin$ env | grep LIBR CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib LD_LIBRARY_PATH=3D{TARGET_DIR}/lib {TARGET_DIR}/bin$ env | grep INCLUDE DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include INCLUDE=3D{TARGET_DIR}/include The error looks the following and produces many more lines of errors: [ 5%] Building CXX object core/apps/snp_store/CMakeFiles/snp_store.dir= /snp_store.cpp.o In Datei, eingef=FCgt von {TARGET_DIR}/seqan-trunk/core/apps/snp_store/= snp_store.cpp:53: {TARGET_DIR}/seqan-trunk/core/apps/snp_store/snp_store.h:36:40: Fehler:= boost/math/distributions.hpp: Datei oder Verzeichnis nicht gefunden However the file{TARGET_DIR}> ls include/boost/math/distributions.hpp=20= include/boost/math/distributions.hpp DOES exist. It is just not found. What am I doing wrong? Any help would be greatly appreciated. Thank you very much, Nomi From manuel.holtgrewe@fu-berlin.de Mon Jun 24 18:47:34 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ur9vR-001QST-3t>; Mon, 24 Jun 2013 18:47:33 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ur9vR-003OAu-1p>; Mon, 24 Jun 2013 18:47:33 +0200 Received: from cas3.campus.fu-berlin.de ([130.133.170.203]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1Ur9vQ-0039FV-Np>; Mon, 24 Jun 2013 18:47:33 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS3.campus.fu-berlin.de ([130.133.170.203]) with mapi id 14.03.0123.003; Mon, 24 Jun 2013 18:47:31 +0200 From: "Holtgrewe, Manuel" To: SeqAn Development Thread-Topic: [Seqan-dev] SeqAn installation with manually compiled boost library Thread-Index: AQHOcPl/RUXbax0OJkCm9G0MYZtiXZlFEhop Message-ID: References: <3003921.rOCDlF5gvM@kagou> In-Reply-To: <3003921.rOCDlF5gvM@kagou> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Mon, 24 Jun 2013 18:47:30 +0200 X-Original-Date: Mon, 24 Jun 2013 16:47:30 +0000 X-Originating-IP: 130.133.170.203 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1372092453-0000097E-0D658BCF/0-11087279796/0-2 X-Bogosity: Ham, tests=bogofilter, spamicity=0.005674, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-49.0 required=5.0 tests=ALL_TRUSTED, FU_XPURGATE_SUSP X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] SeqAn installation with manually compiled boost library X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:47:34 -0000 Dear Nomi,=0A= =0A= this looks as if SeqAn picks up Boost from the system root (i.e. installed = through the Red Hat package manager).=0A= =0A= You have to set the variable "BOOST_ROOT" to the "${TARGET_DIR}/include/boo= st" for the build system to pick up your manual Boost installation.=0A= =0A= If you are lucky, then you can do "ccmake ." in the "bin" directory and sim= ply set the variable.=0A= =0A= If you are less lucky or if you want to have a clean start then you can rem= ove "bin", recreate it and then execute=0A= =0A= cmake ../seqan-trunk -DBOOST_ROOT=3D../include=0A= =0A= Note that you can omit the -DCMAKE_BUILD_TYPE=3DRelease parameter in recent= checkouts (for some months now) since this is the default build type.=0A= =0A= Don't hesitate to send another email if this does not help you.=0A= =0A= Cheers,=0A= Manuel=0A= ________________________________________=0A= From: Nomi Meixner [nomi.meixner@student.uni-tuebingen.de]=0A= Sent: Monday, June 24, 2013 6:39 PM=0A= To: SeqAn Mailing list=0A= Subject: [Seqan-dev] SeqAn installation with manually compiled boost librar= y=0A= =0A= Hello everyone,=0A= =0A= I have trouble installing SeqAn on a RHEL system, where I installed the zli= b and boost libraries manually.=0A= =0A= My folder structure looks the following:=0A= {TARGET_DIR}/bin -> preferred build directory=0A= {TARGET_DIR}/doc=0A= {TARGET_DIR}/include/boost/ -> contains all the boost subfolders .hpp files= etc.=0A= {TARGET_DIR}/lib -> contains libboost* and libz*=0A= {TARGET_DIR}/seqan-trunk -> as checked out from SVN=0A= {TARGET_DIR}/share=0A= =0A= Following the tutorial (trac.seqan.de/wiki/Tutorial/GettingStarted/LinuxMak= efiles), from the {TARGET_DIR}/bin folder I call cmake ../seqan-trunk -DCMA= KE_BUILD_TYPE=3DRelease, which succeeds.=0A= Then >make=0A= Make fails at approximately 5% having trouble to find the boost math librar= ies while installing snp_store.=0A= =0A= The (potentially crucial part of the) environment looks like this:=0A= {TARGET_DIR}/bin$ env | grep CMAKE=0A= CMAKE_MAN_DIR=3D/opt/.../.../cmake/2.8.6/man=0A= CMAKE_DOC_DIR=3D/opt/.../.../cmake/2.8.6/doc=0A= CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= CMAKE_BIN_DIR=3D/opt/.../.../cmake/2.8.6/bin=0A= CMAKE_HOME=3D/opt/.../.../cmake/2.8.6=0A= DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= CMAKE_VERSION=3D2.8.6=0A= CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= =0A= {TARGET_DIR}/bin$ env | grep LIBR=0A= CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= LD_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= =0A= {TARGET_DIR}/bin$ env | grep INCLUDE=0A= DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= INCLUDE=3D{TARGET_DIR}/include=0A= =0A= The error looks the following and produces many more lines of errors:=0A= =0A= [ 5%] Building CXX object core/apps/snp_store/CMakeFiles/snp_store.dir/snp= _store.cpp.o=0A= In Datei, eingef=FCgt von {TARGET_DIR}/seqan-trunk/core/apps/snp_store/snp_= store.cpp:53:=0A= {TARGET_DIR}/seqan-trunk/core/apps/snp_store/snp_store.h:36:40: Fehler: boo= st/math/distributions.hpp: Datei oder Verzeichnis nicht gefunden=0A= =0A= However the file{TARGET_DIR}> ls include/boost/math/distributions.hpp=0A= include/boost/math/distributions.hpp=0A= DOES exist. It is just not found.=0A= =0A= What am I doing wrong?=0A= Any help would be greatly appreciated.=0A= Thank you very much,=0A= =0A= Nomi=0A= =0A= _______________________________________________=0A= seqan-dev mailing list=0A= seqan-dev@lists.fu-berlin.de=0A= https://lists.fu-berlin.de/listinfo/seqan-dev=0A= From manuel.holtgrewe@fu-berlin.de Mon Jun 24 21:23:43 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrCMY-001el0-JL>; Mon, 24 Jun 2013 21:23:42 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrCMY-000WYO-Hl>; Mon, 24 Jun 2013 21:23:42 +0200 Received: from cas2.campus.fu-berlin.de ([130.133.170.202]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrCMY-003TML-7x>; Mon, 24 Jun 2013 21:23:42 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS2.campus.fu-berlin.de ([130.133.170.202]) with mapi id 14.03.0123.003; Mon, 24 Jun 2013 21:23:41 +0200 From: "Holtgrewe, Manuel" To: "seqan-dev@lists.fu-berlin.de" Thread-Topic: [ANN] VCF I/O Tutorial Thread-Index: Ac5xEFTM/s0GJNdiTYaUf+RnSsieyQ== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Mon, 24 Jun 2013 21:23:39 +0200 X-Original-Date: Mon, 24 Jun 2013 19:23:39 +0000 X-Originating-IP: 130.133.170.202 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1372101822-0000097E-F9E982EE/0-11088381294/0-2 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-49.0 required=5.0 tests=ALL_TRUSTED, FU_XPURGATE_SUSP X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: [Seqan-dev] [ANN] VCF I/O Tutorial X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:23:43 -0000 Dear all,=0A= =0A= SeqAn has had the functionality for reading/writing VCF files since the 1.4= .0 release through module vcf_io.=0A= =0A= We are happy that there now also is a Tutorial for using the module vcf_io.= You can find it here:=0A= =0A= http://trac.seqan.de/wiki/Tutorial/VcfIO=0A= =0A= We're happy to receive your feedback and improve our tutorials further!=0A= =0A= Cheers,=0A= Manuel= From nomi.meixner@student.uni-tuebingen.de Tue Jun 25 09:36:07 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrNnJ-002wTO-Tf>; Tue, 25 Jun 2013 09:36:06 +0200 Received: from mx09.uni-tuebingen.de ([134.2.3.2]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrNnJ-003QIE-Qn>; Tue, 25 Jun 2013 09:36:05 +0200 Received: from kagou.localnet (kagou.am10.uni-tuebingen.de [134.2.182.174]) (authenticated bits=0) by mx09.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id r5P7a3Il025098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Jun 2013 09:36:04 +0200 From: Nomi Meixner To: SeqAn Development Date: Tue, 25 Jun 2013 09:35:59 +0200 Message-ID: <1596782.W2Z8TO2AkO@kagou> User-Agent: KMail/4.10.4 (Linux/3.9.6-200.fc18.i686; KDE/4.10.4; i686; ; ) In-Reply-To: References: <3003921.rOCDlF5gvM@kagou> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.26; spam filter version: 3.2.0/2.3; host: mx09) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.2.12.66; VDF: 7.11.86.196; host: mx09); id=2539-sCHzgw X-Originating-IP: 134.2.3.2 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1372145765-0000097E-F68B91C4/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000055, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] SeqAn installation with manually compiled boost library X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:36:07 -0000 Dear Manuel, dear all, > this looks as if SeqAn picks up Boost from the system root (i.e. inst= alled through the Red Hat package manager). >=20 > You have to set the variable "BOOST_ROOT" to the "${TARGET_DIR}/inclu= de/boost" for the build system to pick up your manual Boost installatio= n. >=20 > If you are lucky, then you can do "ccmake ." in the "bin" directory a= nd simply set the variable. >=20 > If you are less lucky or if you want to have a clean start then you c= an remove "bin", recreate it and then execute >=20 > cmake ../seqan-trunk -DBOOST_ROOT=3D../include Thank you very much for this valuable hint! I removed and re-created th= e bin directory and executed the above mentioned command. This indeed s= olves the problem of not finding the boost library. =20 > Don't hesitate to send another email if this does not help you. However, I have to come back to your offer to ask further questions. Th= e next problem is that the installation fails a few steps afterwards. {TARGET_DIR}/seqan-trunk/core/demos/align/global_alignment_banded.cpp:3= :24: Fehler: seqan/base.h: Datei oder Verzeichnis nicht gefunden This time, I agree that the file it is looking for is not present at th= e location it is searching for it: {TARGET_DIR}> find . -iname base.h ./seqan-trunk/extras/apps/insegt/base.h {TARGET_DIR}> find . -iname seqan ./seqan-trunk/extras/include/seqan ./seqan-trunk/core/include/seqan ./seqan-trunk/misc/py_lib/seqan ./seqan-trunk/util/ports/science/seqan ./seqan-trunk/util/py_lib/seqan Where am I supposed to get this file from? And am I right assuming it s= hould go to ./seqan-trunk/core/include/seqan? I hope you can help me again... Let me know, if you need further detail= s like complete output of the process etc. Thank you very much in advance! Best, Nomi > ________________________________________ > From: Nomi Meixner [nomi.meixner@student.uni-tuebingen.de] > Sent: Monday, June 24, 2013 6:39 PM > To: SeqAn Mailing list > Subject: [Seqan-dev] SeqAn installation with manually compiled boost = library >=20 > Hello everyone, >=20 > I have trouble installing SeqAn on a RHEL system, where I installed t= he zlib and boost libraries manually. >=20 > My folder structure looks the following: > {TARGET_DIR}/bin -> preferred build directory > {TARGET_DIR}/doc > {TARGET_DIR}/include/boost/ -> contains all the boost subfolders .hpp= files etc. > {TARGET_DIR}/lib -> contains libboost* and libz* > {TARGET_DIR}/seqan-trunk -> as checked out from SVN > {TARGET_DIR}/share >=20 > Following the tutorial (trac.seqan.de/wiki/Tutorial/GettingStarted/Li= nuxMakefiles), from the {TARGET_DIR}/bin folder I call cmake ../seqan-t= runk -DCMAKE_BUILD_TYPE=3DRelease, which succeeds. > Then >make > Make fails at approximately 5% having trouble to find the boost math = libraries while installing snp_store. >=20 > The (potentially crucial part of the) environment looks like this: > {TARGET_DIR}/bin$ env | grep CMAKE > CMAKE_MAN_DIR=3D/opt/.../.../cmake/2.8.6/man > CMAKE_DOC_DIR=3D/opt/.../.../cmake/2.8.6/doc > CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib > CMAKE_BIN_DIR=3D/opt/.../.../cmake/2.8.6/bin > CMAKE_HOME=3D/opt/.../.../cmake/2.8.6 > DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include > CMAKE_VERSION=3D2.8.6 > CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include >=20 > {TARGET_DIR}/bin$ env | grep LIBR > CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib > LD_LIBRARY_PATH=3D{TARGET_DIR}/lib >=20 > {TARGET_DIR}/bin$ env | grep INCLUDE > DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include > CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include > INCLUDE=3D{TARGET_DIR}/include >=20 > The error looks the following and produces many more lines of errors:= >=20 > [ 5%] Building CXX object core/apps/snp_store/CMakeFiles/snp_store.d= ir/snp_store.cpp.o > In Datei, eingef=FCgt von {TARGET_DIR}/seqan-trunk/core/apps/snp_stor= e/snp_store.cpp:53: > {TARGET_DIR}/seqan-trunk/core/apps/snp_store/snp_store.h:36:40: Fehle= r: boost/math/distributions.hpp: Datei oder Verzeichnis nicht gefunden >=20 > However the file{TARGET_DIR}> ls include/boost/math/distributions.hpp= > include/boost/math/distributions.hpp > DOES exist. It is just not found. >=20 > What am I doing wrong? > Any help would be greatly appreciated. > Thank you very much, >=20 > Nomi >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev From bernd.jagla@pasteur.fr Tue Jun 25 09:48:12 2013 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrNz1-002y8H-EV>; Tue, 25 Jun 2013 09:48:11 +0200 Received: from mail-interne3.pasteur.fr ([157.99.64.82]) by relay1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrNz1-003SOT-Bz>; Tue, 25 Jun 2013 09:48:11 +0200 Received: from maroilles.sis.pasteur.fr (localhost [127.0.0.1]) by mail-interne3.pasteur.fr (Postfix) with ESMTP id B4F92381051 for ; Tue, 25 Jun 2013 09:48:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at pasteur.fr Received: from [127.0.0.1] (zodiac.pt2.pasteur.fr [157.99.241.45]) by mail-interne3.pasteur.fr (Postfix) with ESMTP id 93104381050 for ; Tue, 25 Jun 2013 09:48:09 +0200 (CEST) Message-ID: <51C94B44.1020100@pasteur.fr> Date: Tue, 25 Jun 2013 09:48:20 +0200 From: Bernd Jagla User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: seqan-dev@lists.fu-berlin.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 157.99.64.82 X-purgate: clean X-purgate-type: clean X-purgate-ID: 151147::1372146491-0000097E-651B00E8/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001241, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=3.0 required=5.0 tests=TO_NO_BRKTS_PCNT X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: xx Subject: [Seqan-dev] problem compiling X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:48:12 -0000 Hi, I have just updated from SVN and get the following error message: [ 5%] Building CXX object core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/align/global_alignment_banded.cpp.o /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:3:24: error: seqan/base.h: No such file or directory /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp: In function 'int main()': /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:12: error: 'Dna5String' was not declared in this scope /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:12: error: template argument 1 is invalid /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:12: error: invalid type in declaration before ';' toke n /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:13: error: 'rows' was not declared in this scope /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:13: error: 'resize' was not declared in this scope /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:14: error: 'row' was not declared in this scope /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core/demos/align/global_alignment_banded.cpp:23: error: no matching function for call to 'globalAli gnment(int&, seqan::Score >&, seqan::AlignConfig >&, int&, int&)' make[2]: *** [core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/align/global_alignment_banded.cpp.o] Error 1 make[1]: *** [core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/all] Error 2 make: *** [all] Error 2 I have double checked that there no differences between the local and the remote system... Thanks for your help. Bernd From manuel.holtgrewe@fu-berlin.de Tue Jun 25 10:17:04 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrOQw-0032k1-UP>; Tue, 25 Jun 2013 10:17:03 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrOQw-001GUg-SU>; Tue, 25 Jun 2013 10:17:02 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrOQw-000O4Q-Hv>; Tue, 25 Jun 2013 10:17:02 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 10:17:01 +0200 From: "Holtgrewe, Manuel" To: SeqAn Development Thread-Topic: [Seqan-dev] SeqAn installation with manually compiled boost library Thread-Index: AQHOcXarx/VuBxEZsUqtImAa4iN7pplGFUll Message-ID: References: <3003921.rOCDlF5gvM@kagou> , <1596782.W2Z8TO2AkO@kagou> In-Reply-To: <1596782.W2Z8TO2AkO@kagou> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 25 Jun 2013 10:17:00 +0200 X-Original-Date: Tue, 25 Jun 2013 08:17:00 +0000 X-Originating-IP: 130.133.170.201 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1372148222-0000097E-C992AB55/3913091171-0/0-1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000305, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-49.0 required=5.0 tests=ALL_TRUSTED, FU_XPURGATE_SUSP X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] SeqAn installation with manually compiled boost library X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:17:04 -0000 Dear Nomi, this is a bug in one of our demo programs, it should have been b= asic instead of base.=0A= =0A= It should be fixed now, please update seqan-trunk via SVN and try again.=0A= =0A= Cheers,=0A= Manuel=0A= ________________________________________=0A= From: Nomi Meixner [nomi.meixner@student.uni-tuebingen.de]=0A= Sent: Tuesday, June 25, 2013 9:35 AM=0A= To: SeqAn Development=0A= Subject: Re: [Seqan-dev] SeqAn installation with manually compiled boost = library=0A= =0A= Dear Manuel, dear all,=0A= =0A= > this looks as if SeqAn picks up Boost from the system root (i.e. installe= d through the Red Hat package manager).=0A= >=0A= > You have to set the variable "BOOST_ROOT" to the "${TARGET_DIR}/include/b= oost" for the build system to pick up your manual Boost installation.=0A= >=0A= > If you are lucky, then you can do "ccmake ." in the "bin" directory and s= imply set the variable.=0A= >=0A= > If you are less lucky or if you want to have a clean start then you can r= emove "bin", recreate it and then execute=0A= >=0A= > cmake ../seqan-trunk -DBOOST_ROOT=3D../include=0A= =0A= Thank you very much for this valuable hint! I removed and re-created the bi= n directory and executed the above mentioned command. This indeed solves th= e problem of not finding the boost library.=0A= =0A= > Don't hesitate to send another email if this does not help you.=0A= =0A= However, I have to come back to your offer to ask further questions. The ne= xt problem is that the installation fails a few steps afterwards.=0A= {TARGET_DIR}/seqan-trunk/core/demos/align/global_alignment_banded.cpp:3:24:= Fehler: seqan/base.h: Datei oder Verzeichnis nicht gefunden=0A= =0A= This time, I agree that the file it is looking for is not present at the lo= cation it is searching for it:=0A= {TARGET_DIR}> find . -iname base.h=0A= ./seqan-trunk/extras/apps/insegt/base.h=0A= =0A= {TARGET_DIR}> find . -iname seqan=0A= ./seqan-trunk/extras/include/seqan=0A= ./seqan-trunk/core/include/seqan=0A= ./seqan-trunk/misc/py_lib/seqan=0A= ./seqan-trunk/util/ports/science/seqan=0A= ./seqan-trunk/util/py_lib/seqan=0A= =0A= Where am I supposed to get this file from? And am I right assuming it shoul= d go to ./seqan-trunk/core/include/seqan?=0A= =0A= I hope you can help me again... Let me know, if you need further details li= ke complete output of the process etc.=0A= Thank you very much in advance!=0A= =0A= Best,=0A= Nomi=0A= =0A= > ________________________________________=0A= > From: Nomi Meixner [nomi.meixner@student.uni-tuebingen.de]=0A= > Sent: Monday, June 24, 2013 6:39 PM=0A= > To: SeqAn Mailing list=0A= > Subject: [Seqan-dev] SeqAn installation with manually compiled boost libr= ary=0A= >=0A= > Hello everyone,=0A= >=0A= > I have trouble installing SeqAn on a RHEL system, where I installed the z= lib and boost libraries manually.=0A= >=0A= > My folder structure looks the following:=0A= > {TARGET_DIR}/bin -> preferred build directory=0A= > {TARGET_DIR}/doc=0A= > {TARGET_DIR}/include/boost/ -> contains all the boost subfolders .hpp fil= es etc.=0A= > {TARGET_DIR}/lib -> contains libboost* and libz*=0A= > {TARGET_DIR}/seqan-trunk -> as checked out from SVN=0A= > {TARGET_DIR}/share=0A= >=0A= > Following the tutorial (trac.seqan.de/wiki/Tutorial/GettingStarted/LinuxM= akefiles), from the {TARGET_DIR}/bin folder I call cmake ../seqan-trunk -DC= MAKE_BUILD_TYPE=3DRelease, which succeeds.=0A= > Then >make=0A= > Make fails at approximately 5% having trouble to find the boost math libr= aries while installing snp_store.=0A= >=0A= > The (potentially crucial part of the) environment looks like this:=0A= > {TARGET_DIR}/bin$ env | grep CMAKE=0A= > CMAKE_MAN_DIR=3D/opt/.../.../cmake/2.8.6/man=0A= > CMAKE_DOC_DIR=3D/opt/.../.../cmake/2.8.6/doc=0A= > CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= > CMAKE_BIN_DIR=3D/opt/.../.../cmake/2.8.6/bin=0A= > CMAKE_HOME=3D/opt/.../.../cmake/2.8.6=0A= > DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= > CMAKE_VERSION=3D2.8.6=0A= > CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= >=0A= > {TARGET_DIR}/bin$ env | grep LIBR=0A= > CMAKE_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= > LD_LIBRARY_PATH=3D{TARGET_DIR}/lib=0A= >=0A= > {TARGET_DIR}/bin$ env | grep INCLUDE=0A= > DCMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= > CMAKE_INCLUDE_PATH=3D{TARGET_DIR}/include=0A= > INCLUDE=3D{TARGET_DIR}/include=0A= >=0A= > The error looks the following and produces many more lines of errors:=0A= >=0A= > [ 5%] Building CXX object core/apps/snp_store/CMakeFiles/snp_store.dir/s= np_store.cpp.o=0A= > In Datei, eingef=FCgt von {TARGET_DIR}/seqan-trunk/core/apps/snp_store/sn= p_store.cpp:53:=0A= > {TARGET_DIR}/seqan-trunk/core/apps/snp_store/snp_store.h:36:40: Fehler: b= oost/math/distributions.hpp: Datei oder Verzeichnis nicht gefunden=0A= >=0A= > However the file{TARGET_DIR}> ls include/boost/math/distributions.hpp=0A= > include/boost/math/distributions.hpp=0A= > DOES exist. It is just not found.=0A= >=0A= > What am I doing wrong?=0A= > Any help would be greatly appreciated.=0A= > Thank you very much,=0A= >=0A= > Nomi=0A= >=0A= > _______________________________________________=0A= > seqan-dev mailing list=0A= > seqan-dev@lists.fu-berlin.de=0A= > https://lists.fu-berlin.de/listinfo/seqan-dev=0A= >=0A= > _______________________________________________=0A= > seqan-dev mailing list=0A= > seqan-dev@lists.fu-berlin.de=0A= > https://lists.fu-berlin.de/listinfo/seqan-dev=0A= =0A= _______________________________________________=0A= seqan-dev mailing list=0A= seqan-dev@lists.fu-berlin.de=0A= https://lists.fu-berlin.de/listinfo/seqan-dev=0A= From manuel.holtgrewe@fu-berlin.de Tue Jun 25 10:17:23 2013 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrORG-0032m1-5G>; Tue, 25 Jun 2013 10:17:22 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrORG-001Gnb-3K>; Tue, 25 Jun 2013 10:17:22 +0200 Received: from cas1.campus.fu-berlin.de ([130.133.170.201]) by relay2.zedat.fu-berlin.de (Exim 4.80.1) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1UrORF-000O6R-PT>; Tue, 25 Jun 2013 10:17:22 +0200 Received: from EX02A.campus.fu-berlin.de ([130.133.170.132]) by CAS1.campus.fu-berlin.de ([130.133.170.201]) with mapi id 14.03.0123.003; Tue, 25 Jun 2013 10:17:21 +0200 From: "Holtgrewe, Manuel" To: SeqAn Development Thread-Topic: [Seqan-dev] problem compiling Thread-Index: AQHOcXhZwq8XSKNr0ku9bKvoLRKZV5lGFc3y Message-ID: References: <51C94B44.1020100@pasteur.fr> In-Reply-To: <51C94B44.1020100@pasteur.fr> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 25 Jun 2013 10:17:19 +0200 X-Original-Date: Tue, 25 Jun 2013 08:17:19 +0000 X-Originating-IP: 130.133.170.201 X-purgate: suspect X-purgate-type: suspect X-purgate-ID: 151147::1372148242-0000097E-6021E03B/3913101711-0/0-1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000411, version=1.2.3 X-Spam-Flag: NO X-Spam-Status: No, score=-49.0 required=5.0 tests=ALL_TRUSTED, FU_XPURGATE_SUSP X-Spam-Checker-Version: SpamAssassin 3.3.3-zedat0a54d5a on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: Subject: Re: [Seqan-dev] problem compiling X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.14 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:17:23 -0000 Hi Bernd, this is the same problem as Nomi's.=0A= =0A= Please update and try again.=0A= =0A= Cheers,=0A= Manuel=0A= ________________________________________=0A= From: Bernd Jagla [bernd.jagla@pasteur.fr]=0A= Sent: Tuesday, June 25, 2013 9:48 AM=0A= To: seqan-dev@lists.fu-berlin.de=0A= Subject: [Seqan-dev] problem compiling=0A= =0A= Hi,=0A= =0A= I have just updated from SVN and get the following error message:=0A= =0A= [ 5%] Building CXX object=0A= core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/align/global_a= lignment_banded.cpp.o=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:3:24:=0A= error: seqan/base.h: No such file or directory=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:=0A= In function 'int main()':=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:12:=0A= error: 'Dna5String' was not declared in this scope=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:12:=0A= error: template argument 1 is invalid=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:12:=0A= error: invalid type in declaration before ';' toke=0A= n=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:13:=0A= error: 'rows' was not declared in this scope=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:13:=0A= error: 'resize' was not declared in this scope=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:14:=0A= error: 'row' was not declared in this scope=0A= /pasteur/projets/specific/PF2_ngs/protected/programs/seqan/seqan-trunk/core= /demos/align/global_alignment_banded.cpp:23:=0A= error: no matching function for call to 'globalAli=0A= gnment(int&, seqan::Score >&,=0A= seqan::AlignConfig >&, int&, int&)'=0A= make[2]: ***=0A= [core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/align/global_= alignment_banded.cpp.o]=0A= Error 1=0A= make[1]: ***=0A= [core/demos/CMakeFiles/demo_align_global_alignment_banded.dir/all] Error 2= =0A= make: *** [all] Error 2=0A= =0A= I have double checked that there no differences between the local and=0A= the remote system...=0A= =0A= Thanks for your help.=0A= =0A= Bernd=0A= =0A= _______________________________________________=0A= seqan-dev mailing list=0A= seqan-dev@lists.fu-berlin.de=0A= https://lists.fu-berlin.de/listinfo/seqan-dev=0A=