IUBio GIL .. BIOSCI/Bionet News .. Biosequences .. Software .. FTP

Acedb March Newsletter

Ed Griffiths edgrif at sanger.ac.uk
Thu Apr 19 03:41:54 EST 2001

The March Newsletter, damn - late again, I'll get back on track soon.

Do remember that contributions to the Newsletter would be most welcome, topics
could be anything from "your favourite tip" to "your favourite bug" to "my wish
list". Just send me a few paragraphs and I'll put it in the next newsletter.

cheers Ed

| Ed Griffiths, Acedb development, Informatics Group,                    |
|               The Sanger Centre, Wellcome Trust Genome Campus,         |
|               Hinxton, Cambridge CB10 1SA, UK                          |
|                                                                        |
| email: edgrif at sanger.ac.uk  Tel: +44-1223-494780  Fax: +44-1223-494919 |


ACEDB User Group Newsletter - March 2001

If you want to have this newsletter mailed to you _or_ you want to make
comments/suggestions about the format/content then send an email to
acedb at sanger.ac.uk.

This month sees the first contributions from acedb users to the newsletters,
thanks to Keith Bradnam and Dan Lawson. There are a number of important bug
fixes which in particular affect people who use the giface code to produce
gif versions of fmap etc. Hewlett Packard have contacted the AceDB
developers as they would like AceDB to be part of their IA-64 program.

New Features

exporting of cDNA from non-CDS objects

Previously you could only export the cDNA for a sequence object if that
object was marked as a CDS. In a rigorous way this makes sense but can be
irritating if you have an object for which you'd just like to take a quick
look at the cDNA. This restriction has now been removed so that, provided
the object is in some way "attached" to some DNA, you can export a cDNA for
it. It is of course up to you to interpret what that DNA might mean (!).

log switching

AceDB log files can grow very quickly and up until now a new log file was
only started if the database was reinitialised, or if the existing log file
was moved aside manually. This is not very convenient, particularly when
running an acedb server on a database.

Support has been added to start a new log using the following methods:

     Use the "Newlog" command to start a new log.wrm, you must have write
     access to the database to be able to do this.
     Use the "Serverlog" command to start a new log.wrm and a new
     serverlog.wrm, you must have admin permissions to the database to be
     able to do this.

     You can also send the server a SIGHUP signal which has the same effect,
     but note that if you use this method, the new logs will not be started
     until the _next_ record is written to the relevant log.

"No_display" tag in ?Method objects for F-map display

This article was kindly supplied by Dan Lawson <dl1 at sanger.ac.uk>, he wins a
beer for being the second voluntary contributor to the newsletter.

The way in which objects are displayed in the F-map display is defined by
the Method class. The Method object contains information such as the colour
and column priority for the drawing of the F-map. The Method object also
contains GFF definitions for the labelling of the GFF dumps of an object.

Recently in the worm database we have extended the use of the ?Method tag in
the Sequence class to be bi-functional. The tag continues to point to a
Method object for drawing the F-map but is also used in the generation of
subclasses (similar to using a standard type tag in the Properties e.g.
Genomic_canonical or CDS.) An example of a new Method is 'Link' which
indicates more explicitly which Sequence objects are link objects - i.e.
those which contain the golden path for a group of overlapping genome

As every Sequence will have a Method the xace code will attempt to display
the object in the F-map. If the Method object does not contain colour/column
priority information then the default blue box with a low column priority
will be displayed. Some types of objects should not be displayed in the
F-map (the Link objects are a good example), and so we have introduced a new
tag into the Method class. If you set this tag then all objects using the
Method will not be drawn. The tag is called 'No_display' and should be set
as part of the general Method descriptions.

The above modifications allow features to be dumped to GFF files with
sensible definitions without cluttering the F-map view of a genomic region.
If you have any queries regarding these changes please contact Daniel Lawson
<dl1 at sanger.ac.uk>.


Porting acedb to latest HP machines, including new IA-64 based machines.

Hewlett Packard have recently ported AceDB to their latest
machines/operating system versions and are keen for AceDB to be part of
their "Developers Program" for their new range of IA-64 based machines. The
IA-64 is Intels 64-bit CPU chip and is being used by HP for some of their
new machines. We should be receiving an HP test machine within the next few

Undocumented/hidden features in Acedb

This article was kindly supplied by Keith Bradnam
<keith at thale.life.nottingham.ac.uk>, he wins a beer for being the first
voluntary contributor to the newsletter.

Whilst the quest for the legendary 'Golden Manual of Ace' continues, mere
mortals will have to content themselves with picking up tips and second-hand
rumours from the unchartered back-waters of the internet.

The sometimes-annoying truth is that many useful Acedb features remain
undocumented. But maybe we (the Acedb community) can help to change that.
I'll make a start by revealing a couple of useful Acedb features that I
(accidentally) discovered after browsing the ACeDB (worm) database one day.

1) Adding 'arrows' to sequence displays

It is not always easy to draw attention to tiny features that are present on
very large sequences. E.g. a 50 bp BLAST homology object which is present on
a 200 kb sequence object appears as a narrow black line.

It would also be useful if you could draw attention to a feature by
displaying it in another way, e.g. as an arrow which points to a particular
range of bases (or even a single nucleotide). Well, the good news is that
you can. The trick is to create 'Allele' tags within a sequence object.

Such tags allow you to create an arrow-like object which appears in the
'Alleles' column of the sequence display. Arrows can have a 'direction' (up
or down) as they are accompanied by a smaller, side arrow. They can also
have some associated text which appears on the sequence display.

E.g. consider the following ace file:

Sequence : "EMBL:A47152"
Allele "Test1" 50 100 "Message1"

Allele "Test2" 400 300 "Message 2"
Allele "Test3" 1000 1000 "Message 3"

This file (when read into an appropriate database) will create three arrows
that appear on the sequence display for 'EMBL:A47152'. The first arrow
points to a region of 50 bp (between coordinates 50 and 100) and will
display the accompanying message. Because the second coordinate is larger
than the first, the arrow appears with the smaller side arrow pointing

The second object displays an arrow which will point in the the up direction
(first coordinate larger than the second). The third arrow will also point
upwards but corresponds to a single nucleotide in the sequence.

If you zoom in on these arrows they will eventually transform into 'open
rectangles' (a bit like a ']'). The point at which an arrow turns into an
open rectangle depends on how large a region the Allele tag corresponds to.

If all this sounds a bit confusing, look at these examples which were
created to show the positions of insertion events (note that AceBrowser
displays the arrows a little bit differently from xace):



2) Adding more text information to sequence displays

Apart from the above example, sequence displays don't usually display any
text. Sometimes it would be useful to display a gene name or gene function
(where known) next to a coding sequence on a sequence display.

To add text information, simply add a line that reads 'Show_text' to the
'Coding' Method object, e.g. your Method object should looks something like:

Coding Display Colour BLUE
               Strand_sensitive Show_up_strand
               Overlap_mode Bumpable
               Width 2
               Right_priority 2
       Blixem  Blixem_X

The rules governing what text is displayed seem hard to determine but
contents of 'Remark', 'Gene_name', 'Gene_function' tags always seem to be
displayed. In AceBrowser, these don't always work as stable links when
clicked apon.

Both these examples are heavily used in the Arabidopsis Genome Resource
(AGR) at http://ukcrop.net/agr

Bugs Fixed

Problem with printer list in print window

Several people reported that when they tried to print something from AceDB,
the list of printers in the print window contained large numbers of
blank/unusable buttons which made the print window unusable. This problem
was caused by System Support inadvertantly changing the format of the system
file /etc/printcap which contains the list of printers available. The change
in format meant that acedb no longer correctly parsed the printer names,
hence the blank buttons. The file has now been returned to its previous
(unix standard) format and the print window should now work correctly.

cDNA objects no longer silently created in the database

When using fmap, displaying the cDNA for a gene resulted in the silent
creation of a DNA object for the cDNA. If, after you did this, you did a
save, the cDNA object would also be saved into the database. Over time this
gradually clutters up the database with redundant and unwanted objects. fmap
has now been changed so that the cDNA objects are removed when the fmap
displaying the cDNA is destroyed (e.g. by using the "quit" item from the
main menu).

fmap window title did not get refreshed correctly from tree window

If you reused an fmap window to display an object that you clicked on from
the tree window, in some circumstances the title did not get updated to the
name of the new object in 4_8. This is now fixed.

Help crashes

The help code in AceDB crashed for some cases where it could not find the
help files, this is now fixed.

Setting size for gif maps crashed acedb sometimes.

When using the "gif" submenu from giface or sgifaceserver, it is possible to
set the size of the virtual graph using the "dimensions" option. In cleaning
up the virtual graph code a bug was introduced which meant that when the
dimensions option was used the graph produced would be very small which
resulted in the code looping and consuming memory until it crashed or simply
producing a graph of zero size. This is now fixed.

GIF creation caused acedb to swallow memory.

As part of the clean up of the virtual graph system used to produce gif
versions of AceDB windows, a bug was introduced which resulted in AceDB
gradually using up memory because any data associated with the graph was not
freed correctly. The error was in gifcommand.c, which used the test
aceInIsInteractive() to decide whether to set isGifDisplay to TRUE. This
always fails because command.c (which calls gifcommand.c) always copies the
terminals input into a text string, this is by definition non-interactive !
In addition to this, this test will always fail for the server where no
input is ever interactive. The fix was to initialise isGifDisplay to FALSE,
but it's then set to TRUE by the main()s for giface and sgifaceserver, this
then ensures that sequence and display stuff is freed correctly.

March monthly build now available.

You can pick up the monthly builds from:

Sanger users
External users

Next User Group Meeting - D319, 2.30pm, Thursday, 19th April 2001

!*! Please note changed venue !*!
Ed Griffiths <edgrif at sanger.ac.uk>
Last modified: Wed Apr 18 14:51:03 BST 2001

More information about the Acedb mailing list

Send comments to us at archive@iubioarchive.bio.net