Hi,
What is the computational requirement to host a genome browser? Yes, I know the storage should be depend on our genome size, information to store, etc. But I am looking for a general requirements. I mean the processor needed (core), RAM, etc. I won't specific to any genome browser program here to make thing simplify.
Idea, anyone?
Thanks.
To host data for Integrated Genome Browser, the computational requirements are very light. The main requirement is a reasonably fast internet connection.
To host data for IGB, you set up some Web directories with data and a few meta-data files describing the data.
For instructions on how to set up an IGB QuickLoad site: https://wiki.transvar.org/display/igbman/Creating+QuickLoad+Sites
I have successfully run the UCSC Genome Browser in a Box (Gbib) on a workstation with 8 cores and 62 Gb RAM.
I would certainly contact their help desk (genome@soe.ucsc.edu). Be aware it is a publicly accessible newsfeed too. I have always found them to be friendly and helpful.
Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
version 2.3.6
I am planning to have a local server in my lab to host the genome browser. My concern is to have a fast genome browser without any lagging/slow in action.
I am working with large genomes, i.e. plant genomes. But it's not stick to only 1 genome as we might have more genome assemblies soon. So, do you think an 8 core CPUs with 40Gb RAM is enough for this?
Depends on many factors: the genome(s), which browser software, which tracks and features - but I'd say 8 cores + 40 GB is more than enough. I have a GBrowse installation for the hg18 human genome build + several tracks running on a virtual machine with 2 GB RAM and 1 core, which runs acceptably fast.
Yeah you are true. That's what I'm looking for, some experience story from others. I cant state any browser software at this moment, and which features in particular, because this is still a proposal for having the hardware stuff.
Do you think I need to reduce the RAM to 20GB for example? And put more money on the storage? The reason is, the data will keep increasing later with new assemblies coming in the lab. Before this I plan to have a blade server with compute node (1 unit of 1 x 8 cores CPU with 20/40 GB RAM), storage (2 x 2 TB hard disk drive), and a backup server (1 unit of quad cores CPU with 10 GB RAM). Do you think it is enough? Or too much maybe?
Don't think there's such a thing as "too much" :) Hardware is relatively cheap, buy whatever you can afford knowing that it will easily accommodate your future expansion plans. Your original spec sounds fine to me.
IGB is a desktop tool - which means, the user downloads the browser and runs it like any other software program. (It's written in Java.) The only thing you have to do is set up the data directories on your site so that IGB can access them.
The beauty of this scheme is that IGB takes advantage of the full power of the user's computer - you don't have to do anything special on the server side, except set up the data directories. Thanks to this, it feels very, very fast for users.
Great explanation Ann! Thanks.
Again, I wonder. Can we custom the program? Let say this one:
When we click on the gene, a popup appear with a checkbox list of Blast, Interpro, Gene Ontology. Say we select those 3 options, and click submit or go button, then the analysis of 3 programs are running in separate tab. If I not mistaken, this one is sort of API application, right? So does the program allow us for this modification?
Another example. Can we build the so-called plugin or additional script for bookmark/favorite our gene/feature for further usage?
I know the mentioned requirements are not able in the genome browser program, at the moment. So, my concern is, can we do that using the platform that you suggested.
Yes, you can definitely customize IGB.
IGB has a way to develop new features via plugins, which are special add-on programs that users can add or remove whenever they want. (It is using OSGi and Apache felix.)
How it works:
When users select the Plug-in tab, they see a list of available plug-ins. To add a plug-in, they just select it, and it gets downloaded and added to IGB. Users don't have to restart the program or do anything else. It all gets handled automatically.
A nice example is the NCBI Primer plugin, which lets you run a primer design program at NCBI. When it's added into IGB, it shows an option Primer Blast when you right-click something in IGB. If you select that option, then IGB will run a primer blast at NCBI and open a new Web browser window to show you the results.
To add new functions yourself, you can write a plug-in of your own and distribute the plug-in on the Web in a simple Web directory called a "bundle repository." You then share your plug-ins with users by giving them the URL of the bundle repository, which they add by clicking the Repositories button in the Plug-ins tab. If you want, you can also add your plug-in to the main BioViz plugin repository by getting in touch with the development team, or we can add your bundle repository to the listing already in IGB. I don't think it would be difficult.
Soon we are planning to release an IGB version where the plug-in architecture is much improved. In the past, plug-in developers had to create and edit a lot of configuration files manually, which was unpleasant and time-consuming. The lead IGB developer David Norris is fixing that - it's a top priority after releasing the new installer-enabled IGB because it will make developing IGB much easier and enjoyable.
We'd be happy to help you get started if you want to try it. Just go to bioviz.org and click Get Help for contact information.
Great! Thanks Ann for the explanation. I will have a look on IGB soon. Hope I can fulfill the requirements that I have setup before.
Thanks!