The setup script creates a file called setup.log, contains detailed information on your installation. Email email@example.com with a request for support, and attach your setup.log file to the email. Please do not put the setup.log file directly in the email body.
Next you should set your server's location. This is done via the sv_location console variable. The convar should directly correspond to a flag icon stored in the materials/flags16/ folder, without the .png extension. The maximum length is currently set to 5 characters.The flag icon filenames follow the ISO 3166-1 alpha-2 country codes. ( )
Optionally you can add +host_workshop_collection to your command line to automatically install workshop addons onto your dedicated server.Please see Workshop for Dedicated Servers for help with workshop for dedicated servers.
I don't think I'd put it that way exactly, qdjm. JBrowse is definitely the future of GMOD genome browsers, but it is no where near as feature complete as GBrowse yet. Generally, I suggest that people install both, as you will generally need GBrowse for the functionality it provides, and once you have that installed, installing JBrowse is quite easy, and you can provide both to your users, as different people like different things.
I am the lead author in the \"Choosing a genome browser for a Model Organism Database: surveying the Maize community\" paper. Not everybody in the paper worked on implementing the GMOD tools directly. Some are curators, for example. Also, because we connected elements in the MaizeGDB Genome Browser to appropriate MaizeGDB pages, we also acknowledged Programmers/Database administrators working on the main MaizeGDB site as well. I was the main person who did the GBrowse implementation; but note that our web developer established BLAST tools separately, and we already have a separate curation server, which is not connected to GBrowse MySQL backend. We decided to keep Oracle database (the MaizeGDB main backend database), and GBrowse MySQL separate; and transferred data from time to time from one database to another when we needed to do so.
It is also possible for you to use GBrowse system separately and direct the users to pages that use a different backend database like we do: so if you want to opt out of Chado, you can. Or a separate server that uses the same database. If you follow that route, setting up GBrowse and connecting to MySQL is usually straightforward and the scripts are already available to transfer gff files to MySQL. If you have any problem at that stage, the GMOD community will be more than happy to help you. After you do this, then you can assume your web developer mode and start working on better looking pages for your genetic elements; setting up BLAST server etc.
GMOD basic installation used to be relatively easy, and one would be able to have it running for simple fasta files with chromosomes and their annotations in BED/GFF files in an afternoon. I do remember back in the days that other more complicated data structures would take a long time to hook in, but it may have changed for the better lately.
I started with a simple test installation of GBrowse2 on my Macbook. The test installation took about 3 hours, most of the time spent installing dependencies using CPAN and MacPorts. I followed the instructions in the HowTo. An important point to note: the instructions are quite good, and you should follow them as close as possible! At times I messed up but then I noticed I didn't read carefully and trying to jump ahead. GBrowse is written in Perl and requires BioPerl, other requirements include Apache2 (installed via MacPorts), MySQL (don't install via Macports, compiling takes too long, download it). I needed to add 2 lines to my apache.conf, copy some files and restart the web-server.
After that, I had a local install up, and spent another day playing with the configuration, and working through the configuration tutorial, which I also recommend. GBrowse is highly flexible and configurable with respect to appearance and tracks displayed, everything is done using configuration files, no programming necessary so far.
The easy install is based solely on files and 'in-memory' data; while that works fine for small (test-data) sets, it doesn't scale to a >100 Mbp real genome for me. Next step is to make an install on a dedicated server with a data-base backend.
As the configuration files for GBrose and your project data are the artifacts that contain most modifications and adaptations, it might be advisable to put them under revision control. The easiest way is to use RCS in-place, but once the install gets larger and many people work on it, putting the whole configuration directory tree into revision control (git, SVN) might be preferable.
Chado is a database model for genomic data. It is meant to be used with PostgreSQL (recommended to use postgres 8.4 though I am testing with postgres 9.1). I had experience with MySQL before, but I took a little time to figure out what is different. Chado is bundled with an installer like a normal Perl module:
Installation took about 3 days, but only because there was a single missing dependencies, I sent a support mail and got an answer within few hours. The problem should be fixed in the documentation and now installation should procede without problems.
Out of curiosity, why did you install Apache via MacPorts instead of using the Apache that is already installed on your Macbook If it says to do so in the directions then there may be a good reason, I'm just interested to know.
@SES, for the same reason I don't use the system perl, I don't want to mess with the system installed software (I have less control over update, might eventually break stuff needed elsewhere), and I don't like how apple messed up bsd paths (/Library/WebServer/...).
MAKER is fully MPI compliant and plays well with Open MPI and MPICH2. MAKER is installed and available for iPlant users on the lonestar cluster at the Texas Advanced Computing Center (TACC). Here you can see the entire maize v2 genome can be annotated in a few hours using as few as 500 cpus.
There are two files in particular that you would want to look at when installing MAKER - INSTALL and README. INSTALL gives a brief overview of MAKER and prerequisite installation. Let's take a look at this.
You will see a directory called finished.maker.output and a file called opts.txt. The directory contains all the final results for the example and the file is a MAKER control file that we will discuss in detail later. Each of the other examples will contain a similar results directory and control file.
Next we need to tell MAKER all the details about how we want the annotation process to proceed. Because there can be many variables and options involved in annotation, command line options would be too numerous and cumbersome. Instead MAKER uses a set of configuration files which guide each run. You can create a set of generic configuration files in the current working directory by typing the following.
Control files are run-specific and a separate set of control files will need to be generated for each genome annotated with MAKER. MAKER will look for control files in the current working directory, so it is recommended that MAKER be run in a separate directory containing unique control files for each genome.
You will see the names of a number of MAKER supported executables as well as the path to their location. If you followed the installation instructions correctly, including the instructions for installing prerequisite programs, all executable paths should show up automatically for you. However if the location to any of the executables is not set in your PATH environment variable, as per installation instructions, you will have to add these manually to the maker_exe.ctl file every time you run MAKER.
In this file you will find values you can edit for downstream filtering of BLAST and Exonerate alignments. At the very top of the file you will see that I have the option to tell MAKER whether I prefer to use WU-BLAST or NCBI-BLAST. We want to set this to NCBI-BLAST, since that is what is installed. We can just leave the remaining values as the default.
If you look in the current working directory, you will see that MAKER has created an output directory called dpp_contig.maker.output. The name of the output directory is based on the input genomic sequence file, which in this case was dpp_contig.fasta.
The entries in the dpp_contig_master_datastore_index.log file also indicate that the output files for this contig are stored in the directory dpp_contig_datastore/contig-dpp-500-500/. Knowing where the output is stored may seem trivial, however, input genome fasta files can contain thousands even hundreds-of-thousands of contigs, and many file-systems have performance problems with large numbers of sub-directories and files within a single directory. Even when the underlying file-system handles things gracefully, access via network file-systems can still be an issue. To deal with this problem, MAKER creates a hierarchy of nested sub-directory layers, starting from a 'base', and places the results for a given contig within these datastore of possibly thousands of nested directories. The master_datastore_index.log file this is essential for identifying where the output for a given contig is stored.
As you can see, manually viewing the raw GFF3 file produced by MAKER really isn't that meaningful. While you can identify individual features such as genes, mRNAs, and exons, trying to interpret those features in the context of thousands of other genes and thousands of bases of sequence really can't be done by directly looking at the GFF3 file.
Apollo comes in two flavors a desktop application and a web-application. For a quick look at the annotations the Apollo desktop application is about as easy to use as it gets. We could run Apollo on our AWS server to view our annotations on our laptop by setting up X-11 forwarding, but with a roomful of us running GUIS on a remote server over a shared wireless connection is asking for trouble. So let's copy our genome files to our laptop and view them there. If you don't have Apollo installed on your local machine just follow along for a while on the main screen or a neighbor's computer. 59ce067264