[jkbonfield]

I James,
Thanks for your quick reply. I have a question regarding the template display. Could you post the colour code for the reads in the display

Certainly.

The grey scale levels indicate the mapping quality for the template, from dark grey (bad) to white (good). You can control whether it colours this using the average of each end sequence, the minimum of the two, or the maximum of the two by using the menu towards the top left. Additionally the Filter button allows you to filter out poor quality (or peversely good quality) mapping reads.

However this is only the base colour. It will be changed to one of the following if it fits into another category:

Blue: single ended read. Or more specifically, only *this* end is in the Gap5 database. (That doesn't necessarily mean it was a single ended library.)

Red: Inconsistent orientation. Ie instead of ---> <--- it finds ---> --->, <--- <--- or <--- --->. This needs some more work as certain library construction types (eg 454) will yield ---> ---> as standard. My plan here is to auto-analyse each library and attempt to work out the normal orientation. Then anything abnormal will be labelled as red.

Orange: paired, but the other end isn't visible. It's not actually possible with ease to tell whether the other end is in another contig (most likely) or whether it is a long way away in this contig - significantly off the edge of the screen in other words. The ">>Acc" button (accurate mode) attempts to work out this distinction correctly, but it's slow as it has to read more data in order to figure out the correct location.

The reason for this is that Gap5, being an editor, doesn't actually track *where* the other end is, only the record number. If it was found in the same range query then we know they form a pair, if not we require more searching to figure this out. The reason I don't cache such data is that it would mean contig joining or contig breaking suddenly requires millions of edits (to check whether the intra-contig or inter-contig spanning status needs changing).

Having said that, I just noticed the >>Acc button crashed Gap5 for me on one of my test databases. Oops!

For reads (2nd menu from left; set to "reads") the colours simply indicate forward vs reverse reads. It's not possible in all file formats though to distinguish which is which so sometimes it's simply a case of the "left" one being one colour while the "right" one is another. The main use of this is simply to see the extent that the physical sequence data extends along the insert.

Finally I'd recommend using the Y-spread function when in Template Size mode (left-most menubutton). This mode is the default template display view where the Y coordinate is governed by the size of the insert. Thus structural variations stand out. However you can't easily tell how many lines are stacked up on the same pixel row - it maybe an isolated template or it may be a whole stack of templates with very similar start/end positions. The Y-spread slider basically adds a bit of pseudo-randomness to the Y coordinate making it easier to distinguish between 1 template and lots of templates stacked up at the same coordinates.

James

[darked89]

@jkbonfield

Dear James,

Would it be possible to also put some test database(s) with sequences from various sequencing platforms? Something small just to play with?

Best,

dk

[darked89]

re: libg2c0 on Ubuntu:

Update:
After installing libg2c0 package from the package manager and then http://packages.debian.org/lenny/amd...dc++5/download everything seems to be up and running on ubuntu.

On Ubuntu 9.04 (workstation version on i386) simply installing libg2c0 works. Thanks for the tip

dk

[coldturkey]

I James,
Thanks for your quick reply. I have a question regarding the template display. Could you post the colour code for the reads in the display

regards

Brian

[jkbonfield]

load libiwidgets.so => couldn't load file "libiwidgets.so":

This line you can ignore - the file shouldn't exist anyway.

load libgap5.so => couldn't load file "libgap5.so": libstdc++.so.5: cannot open shared object file: No such file or directory

...

I am running Ubuntu on a 64 bit machine and even installing the libg2c0 package did not work. The other issue is that Ubuntu installs libstdc++.so.6 and I am highly reluctant to change that because of the other software I am running.

You absolutely shouldn't replace the systen libstdc++ version. The above error though is the one which is preventing gap5 from launching. A work around is to find a copy of this library version from somewhere else and simply place it in the unpackged gap5-1.2.1/lib/linux-x86_64-libraries directory. It won't affect any system tools then, but gap5 will find it on start up.

The next build (done very shortly I hope) will solve this; gap5 actually doesn't yet use any C++ and I erroneously link against this library simply because gap4 previously did and I copied it's build configuration without thinking. (The same applies for libg2c0 too.)

James

[Lesley]

Thanks for the quick reply. We still get errors as below:

gap5-1.2.1-linux-x86_64/linux-x86_64-bin/gap5 GiardiaV

load libitcl3.3.so =>
load libitk3.3.so =>
load libiwidgets.so => couldn't load file "libiwidgets.so": libiwidgets.so: cannot open shared object file: No such file or directory
load libgap5.so => couldn't load file "libgap5.so": libstdc++.so.5: cannot open shared object file: No such file or directory
couldn't load file "libtgap.so": /gap5-1.2.1-linux-x86_64/linux-x86_64-bin/../lib/linux-x86_64-binaries/libtgap.so: undefined symbol: set_dna_lookup
while executing
"load libtgap.so g5"
(file "/gap5-1.2.1-linux-x86_64/linux-x86_64-bin/../lib/gap5/gap.tcl" line 504)

I am running Ubuntu on a 64 bit machine and even installing the libg2c0 package did not work. The other issue is that Ubuntu installs libstdc++.so.6 and I am highly reluctant to change that because of the other software I am running.
I hope you can find the answer,
Cheers,
Lesley

[jkbonfield]

There's no manual at present. I'm trying to keep it similar to gap4 for usage, so the gap4 manual could be heavily pilfered for suitable documentation.

The main new display in gap5 though is the template display. Gap4 had it, but it was slow and very cluttered for anything but the smallest of contigs. I'll have to right docs from scratch for that, however it's still being heavily modified too.

Given the bad lack of documentation though, I'm happy to field questions. If I get too many it'll just encourage me to write a manual. :-)

James

[coldturkey]

Is there a Gap5 Manual? or will there be.

[jkbonfield]

Hi,

I ran tg_index on a Consed ace file assembly of illumina reads & it appeared to work without any errors.

But when I open the converted gap5.aux file there is just the Refseq sequence in the contig & no sequences. When I try to edit contig I get this message.

Sorry to see that. I did recently spot and fix a bug involving long annotations (aka tags); anything longer than 1K could potentially cause a crash. The fix is in the CVS tree already and will make it into the 1.2.2 release whenever that happens.

However I doubt that's the case here. Gap5 currently doesn't have special support for reference sequences, so the only way they'd appear in the assembly is if there is a single very long sequence added to the assembly itself. In theory this should work just fine, but isn't something I've tested much.

Would it be possible to obtain a temporary copy of your data set to debug the program with?

Thanks,

James

[jkbonfield]

load libgap5.so => couldn't load file "libgap5.so": libg2c.so.0: cannot open shared object file: No such file or directory

I'm rather suprised I still have a dependency on that, but the Gap5 build was derived from Gap4 so perhaps I still link against that library despite not using it. (It's the GNU FORTRAN 77 run-time library.)

Update:
After installing libg2c0 package from the package manager and then http://packages.debian.org/lenny/amd...dc++5/download everything seems to be up and running on ubuntu.

Ah, pretty much as I expected then. I'll try and reduce these dependencies, and more importantly document them too, for the next release. Ideal would be a proper .deb package, but that requires a lot more work and ultimately ends up needing umpteen variants for every linux OS out there which I'd rather avoid.

Thanks for the feedback.

James

[alig]

gap5 aborts

Hi,

I ran tg_index on a Consed ace file assembly of illumina reads & it appeared to work without any errors.

But when I open the converted gap5.aux file there is just the Refseq sequence in the contig & no sequences. When I try to edit contig I get this message.

Level 1: EditContig2 io=0xf731d0 .cedialog .cedialog.id
Thu 18 Jun 12:56:57 2009 signal_handler: Program terminated unexpectedly with signal 11.
Thu 18 Jun 12:56:57 2009 signal_handler: This is probably a bug.
Thu 18 Jun 12:56:57 2009 signal_handler: Please report all bug reports at https://sourceforge.net/projects/staden/
Aborted

can anyone help?

alig

[torrey]

Hi James,
I am getting the same error as Lesley... I am also on an Ubuntu box. Here is the debug output for the error

load libitcl3.3.so =>
load libitk3.3.so =>
load libiwidgets.so => couldn't load file "libiwidgets.so": libiwidgets.so: cannot open shared object file: No such file or directory
load libgap5.so => couldn't load file "libgap5.so": libg2c.so.0: cannot open shared object file: No such file or directory
couldn't load file "libtgap.so": /home/rtewhey/genome/staden/linux-x86_64-bin/../lib/linux-x86_64-binaries/libtgap.so: undefined symbol: set_dna_lookup
while executing
"load libtgap.so g5"
(file "/home/rtewhey/genome/staden/linux-x86_64-bin/../lib/gap5/gap.tcl" line 504)

best


Update:
After installing libg2c0 package from the package manager and then http://packages.debian.org/lenny/amd...dc++5/download everything seems to be up and running on ubuntu.

[jkbonfield]

Sorry to hear it's failing to load for you.

Can you please try setting the STADEN_DEBUG environment variable and running again? It won't make it work, but it may indicate the cause of the problem.

The set_dna_lookup symbol is in the libseq_utils.so library that is shipped with the program, in gap5-1.2.1/lib/linux-x86_64-binaries directory. The gap5 wrapper script it meant to automatically set up LD_LIBRARY_PATH and similar to include this directory, but maybe it's still missing a dependency.

(It will say soemthing like "couldn't load file "libiwidgets.so", but that's normal as it doesn't exist for anyone, but I'm expecting there is also some complaint about symbols in libseq_utils.so judging by your error.)

I built it using a rather aging Debian system (Sarge), due to our systems here being somewhat behind the time in OS releases, hence the issues with library versions. I can rebuild it on etch and make another test available if needed though, but I don't have access to Ubuntu currently.

James

PS. My current project though is to simplify the build system so people can just download the source and type "make" to get something working, but it's a non-trivial process due to some poorly supported dependencies right now.

[Lesley]

Brilliant, we have been awaiting Gap5 since it was marketed so heavily by Illumina when they began marking the Genome Analyser (before the software was ready of course).
I am running a 64 bit Ubuntu 9.04 machine and I managed to get the tg_index working by creating symbolic links for the libssl libraries which by default are 0.9.8, not the 0.9.7 required by the script.
I have run into problems with the gap5 script though and get the following error message:
couldn't load file "libtgap.so": /gap5-1.2.1-linux-x86_64/linux-x86_64-bin/../lib/linux-x86_64-binaries/libtgap.so: undefined symbol: set_dna_lookup
while executing
"load libtgap.so g5"
(file "/gap5-1.2.1-linux-x86_64/linux-x86_64-bin/../lib/gap5/gap.tcl" line 504)
This one is beyond what I can fix. Any ideas?
Cheers,
Lesley

[jkbonfield]

I've now built binaries for 1.2.1 too and placed on sourceforge at:

https://sourceforge.net/project/showfiles.php?group_id=100316&package_id=317355&release_id=689951

For those that downloaded the previous version - there's little change except for:

1) Bug fixed handling of trace names (only an issue sometimes, and only if importing from BAF or ACE).
2) Improved caf2baf perl script
3) Rebuilt everything with optimisation turned on, so it'll be slightly faster now. (The difference probably isn't as significant as you'd think as a lot of time was spent in already optimised third party libraries such as zlib.)

James