Ccaffeine - a CCA component framework for parallel computing
This is a Common Component Architecture prototype framework for distributed
memory message passing High Performance Computing. The name Ccaffeine
no longer stands for anything in particular. Ccaffeine is largely
a product of the High Performance Computing Research Division at Sandia National
Labs in Livermore, but also has benefited from many contributions from other
labs and Universities. This web page is to be converted to a weblog
as soon as I can get someone to install one Slashcode, in the meantime this
is something handtooled to tide us over. Ccaffeine documentation can be found here.
Final feature set for SC03 Ccaffeine is in.
Decided to tag it "lemur" because that is an animal that Joe thinks is
scary. Quick checkout:
cvs -d $USER@cca-forum.org:/cvs/ccaffeine/repository co -r lemur ccafe
A better description along with a complete build transcript is
Make sure you update the cca-spec-babel too, the new "goodbye kiss"
pattern is in it per the last vote. Note that Ccaffeine implements
the ComponentRelease interface and no longer does a
setServices with a null object to signal imminent destruction.
Note also that the "classic" binding to Ccaffeine still behaves
in the same way.
Python install ready
cvs -d $USER@cca-forum.org:/cvs/ccaffeine/repository co -r Python ccafe
cvs -d $USER@cca-forum.org:/cvs/cca-spec/repository co -r Python cca-spec-babel
You need both the new cca-spec-babel and the new Ccaffeine. Make sure
you have Python installed with the right Babelized libpython.so. Then
use --with-babel-python in the configure for both cca-spec-babel and
for ccaffeine. Let me know if there is a problem.
gcc >= 3.1 works with Ccaffeine now, important caveats though:
This information applies to the latest tar-ball
which works fine with gcc 3.2. If you are using Ccaffeine scripting
language (affectionately know as "BenSpeak") then please note that the
friendly people at Gnu have changed (corrected?) the way .so's are
loaded. You must use "repository get-global" where you
might have used (and gotten away with) "repository get" before. This
has caused no end of problems even though Ben has warned us repeatedly
:-). The major symptom is that components are successfully connected
and the port obtained through getPort() , but the
dynamic_cast fails for no apparent reason. Using "repository
get-global" will fix this.
A PortTranslator facility is now available, allowing the use of dynamic
parameters in components.
Download the latest tarball here, or if your
feeling gutsy you can check out a fresh copy directly from CVS. If
you have access to the cca-forum.org machine do this:
cvs -d $USER@cca-forum.org:/home/ccaffeine/repository co -r "babelification" ccafe
or just use anonymous CVS checkout.
It should just build as usual, exactly the same as you already have it.
I have accomplished this by creating a special Babel gov::cca::Port
called the PortTranslator. It has a method on it called getClassicPort
that returns a classic::gov::cca::Port*. Translation is handled
automatically: all you do is ask for a classic port by type, and it comes
to you wrapped in a PortTranslator. Moreover, you can decorate your
component with classic ports (like a ParameterPort) by wrapping the
classic port in a PortTranslator and exporting via addProvidesPort
in the usual way. The biggest headache comes from the fact that all
foreign entities must go through an opaque data type in Babel, and that translates
into a void*. Here is an example of the Ccaffeine
build for this distro.
An example of building
the new(er) Babel-enabled Ccaffeine.
Download the Babel-enabled Ccaffeine here.
Ccaffeine man page for using
it after it is built.
paper that appeared in Concurrency:
The CCA Core Specification in a Distributed Memory SPMD Framework,
Concurrency Computat. 2002;14:1-23.
Some notes on how to build the old Ccaffeine
from the SC01 demo distribution.
These build notes apply only to the tar source distribution