With each release of MacVector as well as adding new features we continually redesign and rewrite many existing parts of MacVector. This is done for a number of reasons. For example:

As a recent example you can now run a primer analysis and literally drag and drop a primer pair or their product to the sequence window to annotate those features to the sequence.

Here’s a few of those general improvements that have been included in MacVector 12.5.

Interface improvements

Sequence Window Enhancements

Miscellaneous Enhancements

..and remember if you want to add Assembler before MacVector 12.5 is released you can do so at half price. You can also purchase an upgrade or a new license before the release of MacVector 12.5 and get a 10% discount. Both these offers include a free upgrade to MacVector 12.5 when it is released. Please request a quote now. Don’t forget to quote the promotional code of “Assembler50%” or “MV12510″ for the discounts.

Technorati Tags: bowtie, MacVector

Some analyses with MacVector will take seconds and as such are done in the foreground. However, some types of analysis can take literally hours and if performed in the foreground they could tie up your Mac for a long time. MacVector has a tool called the Job Manager, whose sole purpose is to control such long running tasks. Once such a task is run MacVector will pass over control directly to the Job Manager, allowing the user to continue to use MacVector. As subsequent jobs are submitted it will store them in the job queue, only allowing them to run when there is a spare CPU (or core) to do so! Blast, alignments, primer design and sequence assembly are all examples of jobs that are submitted to the Job Manager.

Usually once a job has completed the Job Manager will notify the user using in the usual way by bouncing the MacVector icon in the Dock.

Growl is a third party open notification framework for OS X. It allows the basic notification system used by OS X (i.e. the bouncing icon!), to be replaced by a much more flexible, and potentially less intrusive system. It is widely supported by many OS X apps as a complete replacement for the OS X one.

We’re pleased to say that with MacVector 11.1 we’ve added support for Growl to the Job Manager.

Now whenever a job, that is running in the Job Manger completes it notifies you with a non-intrusive way. For example in the image above a Blast job has finished and Growl notifies you with the default theme, “Smoke”. If you click on the dialog then it will take you to the Job Manager where you can display the results. Otherwise it will quietly fade away. Although you’ll never forget you have results to view as the MacVector icon in the Dock will show the number of completed jobs available in the Job Manager!

MacVector 11.1 will be released very shortly.

Technorati Tags:
MacVector, growl

An good example of one of these bugs is a recurring one we’ve found with early versions of OS X 10.4 (Tiger). We’ve had many users report this one. The bug in the operating system causes MacVector to crash when loading the “online update” message from our website. Quite annoying and not our fault we assure you! Updating to 10.4.11 (the last update of this OS) solves the problem.

A more current example is a bug that we have just found in the search function of the file open dialogue. If you regularly use this to open files, and you have recently upgraded to Snow Leopard, then it is likely that you will start experiencing some hangs. Unfortunately once again the bug appears with OS X and not with MacVector, so there’s not a lot we can do! We’ve reported the bug to Apple. In the meantime we recommend using a different way to open your files until the bug is fixed!

One of the major changes was in MacVector 10. Prior to this release single sequences were displayed in the sequence editor with static views of the graphical map and feature table available from this single window. The actual sequence was only represented in the editor. In MacVector 10 this changed to a tabbed window with multiple dynamic views representing the same sequence model underneath. With this more flexible approach regardless of which view you are looking at, or modifying, you are acting on the sequence directly. Furthermore because of this single sequence model all windows are linked, and you can view multiple windows (we call them replicas) of that same sequence. For example with three replicas open, one showing the sequence, another the feature table and the third the map view, then if you select a gene feature in the Feature table, then the sequence representing that gene will be highlighted, and the feature in the Map window will also be highlighted. This is great for visualising your sequences. Especially with large ones.

However, this major change has left quite a few legacy functions that do not fit the new model so well. One such function is the linear/circular button in the floating graphics palette. This button has always been a visual function, and it does not affect the real topology of the sequence underneath. There are times when it is nice to display a circular sequence in linear mode – when you want to zoom in on a crowded region for example, or looking at the MCS of a plasmid whilst cloning fragments.

This made complete sense with the old sequence model of MacVector. However with the new unified tabbed windows viewing a circular view of a linear sequence gives the incorrect impression that you are viewing a circular sequence. Thus meaning that some algorithms would provide unexpected results. A classic example is the cloning vector pBR322, which has an EcoRI site that crosses the origin. As a plasmid the sequence’s topology should be circular. However, if you have toggled the topology button in the sequence window, the sequence is now linear and the EcoR I site disappears. Prior to MacVector 11 if you now viewed this as a circular plasmid the restriction site is still absent, yet the molecule appears to be circular. That’s going to produce a confusing set of fragments on a gel!

We thought that it was safer to change this behaviour in MacVector 11, and so now although you can view a circular molecule as linear, you cannot view a linear molecule as a circular one. We could not think of any user need for viewing a linear sequence as circular, although there are many advantages for viewing a circular sequence as linear. e.g. the aforementioned example of viewing the MCS of a plasmid. So now whenever you view a linear sequence the floating graphics palette linear/circular button is disabled to prevent you from inadvertently changing the Map and *thinking* you are dealing with a circular molecule. It’s a fairly small change, but unfortunately it has confused quite a few users! We do think that it is safer to have made this change. Displaying misleading results is something that we definitely do not want to do!

Currently, only the restriction enzyme, subsequence searching and (most) nucleic acid toolbox plots consider linearity/circularity in their algorithms. However, we plan on adding much better support for circular sequences in MacVector 11.5, so we thought it important to clean up this ambiguous linear/circular issue in this release. To this end, you will also see that the Topology button has now been added to the default toolbar button set of all the sequence window tabs to help indicate it is an important property of the sequence.

On August 28th Apple Computer, Inc. publicly release Mac OS X 10.6 also known as Snow Leopard. With any new release of the operating system (OS) there is always the question of whether the applications you own will continue to work. Often companies will release a new version of their application that fixes any issues that it might have with the new OS. At MacVector, Inc. we work to make sure that our applications already support the new OS releases. MacVector 11.0 and MacVector Assembler 11.0 have been tested with Snow Leopard and any necessary fixes have already been made to keep our applications running on the latest OS from Apple Computer, Inc.

As ardent Mac fans we’re as excited as ever about this new OS, and even though we’re running development builds already, we’ll be first in line on Friday to purchase our shrink wrapped copies!

Talking of releases don’t forget if you are still running an old copy of MacVector you can upgrade at a highly discounted price here.

Phrap was one of the first real high throughput assemblers that could also deal with quality scores (generated by its stablemate Phred). The general input files to Phrap are a single Fasta file containing the reads, and an associated Qual file that contains quality scores for each and every read in the Fasta file. I’m not sure what it is about bioinformaticians, but they always feel the need to add Yet Another Format rather than reuse one of the many decent formats. However, in this case Fastq is a logical progression of the Fasta + Qual format in that the two individual files are now merged. That is each read comprises of four lines; A label header, a sequence, and second label header and a quality score line.

Here’s an example of such a file. Note that this example has a single ‘+’ character to indicate the quality label line, rather than a duplicate of the label.

@ERR000955.3982 IL6_1091:3:1:210:502/1
TCCAAACACACTTTGTGTAGAATCTGCAAGTGGAGAT
+
>>>>>>>>>>>>>>>>>>>;>>>>><>>>;>>;><>>

Many of the raw file formats (sff/ SRF etc) are big! They contain the raw image files as well as basecalled sequence and quality data. Fastq files are at the complete opposite end. They are small, and only contain minimal data. They may contain millions of reads, yet are still in the less than a tenth of a Gigabyte range for a single run’s data. It is worthwhile noting that the various Short Read Archives (NCBI, EBI etc.) require the submission of original raw image files, but only allow the reads to be downloaded in fastq format.

The quality line must comprise of the same number of characters as bases. i.e. one quality character per base. However, most quality scores are double digits. Fastq gets around this by using an ASCII character to encode the quality score. However, here’s where consistency fails. The quaility line mat be one of three different types. Sanger format will encode a Phred quality score of 0 – 60 using the ASCII characters 33 to 93. The latest Illumina 1.3 format will also contain a Phred Quality score from 0 to 40 however, this time encoded using ASCII 64 to 104. Finally the older Illumina (nee Solexa) 1.0 format has its own Solexa/Illumina quality score from -5 to 40 encoded using ASCII 59 to 104. Of course this does now pose problems, as unless you know which quality score was used, there is now way of knowing without guesswork, which it is.

There are also other issues with this format. It could be said that the label line for the quality score line is redundant, and the filesize could be reduced by 25% if this was removed. Some applications do generate and accept fastq files that have a single ‘@’ or ‘+’ in place of the quality label line.

It would be helpful to see a tightening of this format and indeed there is a fastq2 format that does not have these weaknesses.

With the next release of MacVector and Assembler during the Summer we will be adding support for the Fastq format. We will also be adding support for de novo assembly of short read data. This release is currently in internal beta testing, and will be out for a public beta trial soon.

Technorati Tags:
MacVector

There are probably as many different approaches to software bugs as there are software applications. And none of them are perfect – I can’t think of a single application or OS that hasn’t crashed on me at least once over the years. So given that bugs are a reality in most (all?) software products, what is the best approach to reducing their impact once the product has been released? As a Product Manager over the past 10+ years, I’ve been involved in 20 to 30 major releases and probably twice as many minor ones across a variety of products and platforms. They all had one thing in common – within 2 weeks of release, at least one customer reported a bug that, had we known about it before release, we would have fixed before it went out.

At one company I was at, the policy was to “test, test, test” with the QA department somewhat removed from the R&D department.  A huge battery of mostly manual tests was run on every release. If a single line of code was changed, all had to be run again, on every combination of OS and platform supported. Each round of testing took a minimum of a week with every developer pulled off coding to help. Finally, the product was released and, inevitably, a bug report would come in almost straight away.. But, because of the extended release cycle, fixing that bug would take all of the developers and testers time for two weeks, during which time other bug reports would come in. In this way, four months pass before a patch was released, during which time no progress has been made on the next major release. This starts a vicious cycle where at the release post mortem, the QA department insists on more testing for the next version, so that release gets delayed even longer and when the inevitable bug reports come in, an even longer delay before that patch is released.

At MacVector, Inc, we’ve taken a more streamlined approach. We certainly do a lot of testing, but we rely on a much tighter integration between the QA and R+D departments to only retest areas that the developer believes would have been affected by the bug fix. That reduces our bug fix development cycle time dramatically, so we can have patch releases posted on the web site within a week of the initial report. The risks, of course, are those “Whack-a-Mole” bug fixes where the code to fix one bug reveals another bug elsewhere in the application. But if that happens, we know we can turn around a second bug fix in a week or so, not the six months that my old company took.

So the take home lessons are (a) check back to the MacVector web site often to pick up any new patches and (b) I really need to find out where those ants are coming from…