BioCoRE Collaboratory FAQ :
Won't BioCoRE be too bandwidth/computationally expensive?
On Wed, Mar 15, 2000 at 10:43:34PM -0800, Eugene Leitl wrote:
> So, how many truckloads of DEC (Compaq) Alphas have been shipped to > UIUC recently? ;)
Well, we could always use a few more...
BioCoRE development is still in the early stages. We have several tools working now, and we have many more ideas which we plan to implement. Thanks for the comments. At this stage, comments and ideas are especially useful. <p> > Seriously, for system sizes and user numbers beyond the trivial we're > talking serious amounts of tightly coupled iron here (you do mention > "Interactive MD" in "Description"). Also, (with the possible exception > of server-side Java), Java VM implementations are known to be so buggy > and slow to be unusable in practice.
The goal of BioCoRE is to provide integrated tools necessary for researchers in structural biology. Many of those tools, (eg. collaboration notebooks, tools for writing documents/papers) are not particularly bandwidth-intensive, yet would simplify the work of researchers.
Some tools such as Interactive MD, do require fairly low-latency connections to remote computers (roughly 10Mb/s ethernet speeds, not more exotic LAN technologies). In the next few years, we expect such connectivity to be available to an increasing percentage of our users. In fact, it's the high bandwidth promise of the NGI (Next Generation Internet) which will be available to scientists in many academic research institutions, that has been one of the driving forces behind BioCoRE.
At the same time, we are thinking about a number of solutions which would allow more interaction between researchers, without requiring great bandwidth. Here's one example: consider researchers working at several sites. Several meet on a BioCoRE chat channel, or in some kind of video conference, to discuss some work. They run VMD and bring up views of their molecules. When one person wants to discuss a particular view to discuss with the others, he triggers a "Publish" function, which connects to the others' VMD sessions and replicates the view. Such a function will not require nearly the bandwidth of IMD, while still facilitating the kind of cooperation which currently requires a face-to-face meeting.
Currently, we are only planning to use Java for various kinds of network interaction and interface layers, not the hard-core computational components of the collaboratory. So we believe that the performance problems with Java will be secondary. If performance turns out to be a problem, we have no aversion to more traditional languages.
> I haven't missed the frequent occurance of "distributed" in your > overview article, but does it really work in practice? (I know > VMD/NAMD does, but your approach seems to be different, both because > of use of nonlocal networking with necessarily poor latency and > throughput, and trivial portability at the price of very poor > performance due to Java).
Well, this is ongoing work, but we are fairly confident that our distributed approach will work. Part of the research will be to discover what works now, and what will work with the infrastructure a few years down the road. We don't plan on re-creating functionality unless it is absolutely necessary. Our approach is to connect up existing component (such as VMD and NAMD) whenever possible. We think that Java will be a good tool for such connections.
Why do you CapItaLIze BioCoRE the way you do?