Subject: Re: BioCoRE - a structural biology portal

From: Robert Brunner <[email-masked]>
Date: Thu, 16 Mar 2000 22:24:30 -0600

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.

> 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.
 
If you want to contact us directly, send email to
[email-masked].

Robert Brunner
[email-masked]