There is a graphical front-end for Ccaffeine (known as ccafe-gui,
or “the GUI”) which provides a fairly simple visual
programming metaphor for the assembly of applications using CCA
components. If you've been through the previous sections of this
chapter, you'll already recognize that using the GUI is entirely
optional. As with many environments that offer both graphical and
non-graphical interfaces, we find that new/inexperienced users
tend to like the GUI, while once they “get the hang”
of using the CCA, they tend to prefer text-based scripting, as in
Section 2.2, “
Running Ccaffeine Using an rc File
”.
In this section, we'll present the same sequence of operations as
in Section 2.1, “A CCA Application in Detail” and Section 2.2, “
Running Ccaffeine Using an rc File
” using the GUI. We'll focus on the
mechanics of using the GUI and assume that you've work through (or
at least read) the previous sections to understand what's going on
in the Ccaffeine instance running behind the GUI, and in the CCA
components within Ccaffeine.
Ccaffeine and its GUI are run as two separate processes, possibly on two different machines. In any event, you'll need two separate terminal sessions to control and monitor the two processes. We will refer to these as “Ccaffeine host” and “GUI host”.
In this exercise, we will invoke Ccaffeine on the Ccaffeine host with:
gui-backend.sh --port3314\--ccafe-rc
rc_file\![]()
The default for ccafe-client (and
ccafe-batch) is to direct most of their own
output, as well as the output from applications within them, to
files named pOut
(for the stdout stream) and
npErr (for the
stderr stream), where
n denotes the MPI
rank of the process. (In this Guide, we'll be running
sequentially, so we'll have only npOut0 and
pErr0.) The gui-backend.sh
script invokes ccafe-client with the
--ccafe-io2tty to direct its output to the
terminal instead of to the files (the files will still be created,
but will contain just a few startup messages relating to the MPI
rank and the process id). Using --ccafe-io2tty
is more convenient for more interactive development work, but if
you're going to run an actual application, you probably want to
capture the output in the files instead. With the current
gui-backend.sh, this would require modifying
the script, but for “production” computing with CCA,
we expect most people to use the rc approach of the
previous section rather than the GUI.
The Ccaffeine GUI is implemented in Java, and is available as a
jar file that can be used
with any recent version of the Java runtime or the full software
development kit. Because the Java invocation is long and hard
to remember, we provide convenience scripts to simplify using
it. Which one you need depends on your circumstances:
This is the script to use if you're running the GUI on the same machine as the backend. This script is configured and installed as part of the CCA tools build process.
This is the script to use if you're running the GUI on a
Linux-like machine and want to
connect to Ccaffeine running remotely.
You will need to download this to your local machine,
along with the GUI's jar file, following the
directions in Section B.2, “The Ccaffeine GUI”.
This is the script to use if you're running the GUI on a
Windows machine and want to connect
to Ccaffeine running remotely. You
will need to download this to your local machine, along
with the GUI's jar
file, following the directions in Section B.2, “The Ccaffeine GUI”.
Below, we will refer to simple-gui.sh, but you should replace it with whichever command is appropriate for your situation.
![]() |
Note |
|---|---|
|
While the GUI can be run remotely, using the X11 protocol to display on your local X11 server, this is generally unacceptably slow because of the way Java handles graphics in X11. You will probably get more satisfactory performance if you can run the GUI on your local system and allow it to connect over the network to the remote host where you're running Ccaffeine. Tunneling the GUI-Ccaffeine connection over your ssh connection is a straightforward way to deal with firewalls that often prevent direct access to most ports on remote hosts. It has the added advantage, for the purposes of this Guide, that you would use the same arguments to invoke the GUI running remotely through a tunnel or locally on the same machine as the backend. For more information, see Appendix A, Remote Access for the CCA Environment and in particular Section A.3, “Tunneling other Connections through SSH”. |
In this exercise, we will invoke the GUI on the GUI host with:
simple-gui.sh --builderPort3314\--host
localhost![]()
|
This tells the GUI which port to use for the connection to
Ccaffeine host. In general, it should match the
ccafe-client |
|
This tells the GUI which host to connect to for the Ccaffeine
backend. In general, it should be the Ccaffeine host (though when
tunneling the connection through ssh, it would be |
![]() |
Note |
|---|---|
|
Since gui.sh is designed to be used on the same machine as Ccaffeine is running on, it does not take a --host argument. The simple-gui scripts do require it. |
![]() |
Note |
|---|---|
|
Ccaffeine should be running and ready to receive the GUI's connection before you start the GUI. If you're scripting their execution, especially on the same machine, the sleep command can help build in a few seconds of delay. |
![]() |
Note |
|---|---|
|
Once the GUI displays on your screen, it may take a few more seconds before it will respond to user actions. |
Run gui-backend.sh on the Ccaffeine host
using the appropriate port and the
task0_gui_rc rc file. The
command will look something like:
gui-backend.sh --port3314--ccafe-rc$TUTORIAL_SRC/components/examples/task0_gui_rc
depending on the port number assigned to you, and whether or
not you've copied the rc file to your local directory.
In the Ccaffeine host terminal window, you will see something like:
(Ccaffeine host)
(19419) CmdLineClientMain.cxx: execName is ccafe-client
(19419) CmdLineClientMain.cxx: runType is CLIENT
(19419) CmdLineClientMain.cxx: If execName is unexpected, blame your MPI startup script.
(19419) CmdLineClientMain.cxx: If MPI_Init is unwanted, try adding the switch '--ccafe-mpi no' switch,
(19419) CmdLineClientMain.cxx: or try setenv CCAFE_USE_MPI 0 .
(19419) CmdLineClientMain.cxx: MPI_Init being called.
(19419) CmdLineClientMain.cxx: MPI_Init succeeded.
(19419) my rank: 0, my pid: 19419
(19419) MapEverythingToFile(pOut0, pErr0)
Type: Server
which is similar to what you saw running
ccafe-single in Step 1 of Section 2.1, “A CCA Application in Detail”, except that in
ccafe-client, MPI is configured
“on” by default. The next-to-last line is
special to ccafe-client (and
ccafe-batch) and serves as a reminder that
by default, the stdout and stderr output streams from these
executables are funneled to the indicated files. This message
appears (and the files are created, but with minimal content)
even though we used the --ccafe-io2tty
option.
Run the simple-gui.sh on the GUI host.
Once the GUI connects to Ccaffeine, Ccaffeine begins running the
rc file it was invoked with. In the GUI host
terminal window, you first see some startup messages from the
GUI itself, followed by a series of messages as Ccaffeine
processes the rc file and the GUI displays the
results. These are debugging messages and can largely be
ignored. In the Ccaffeine host terminal, you should see some
additional messages as Ccaffeine processes the rc file,
like:
(Ccaffeine host)
CCAFFEINE configured with babel.
CmdLineClient parsing ...
CmdContextCCAMPI::initRC: Found /san/homedirs/bernhold/task0_gui_rc.
# There are allegedly 31 classes in the component path
Finally, you should see a
“gui>” prompt in the
GUI host terminal window, and the GUI itself should have
appeared on your display, looking something like this:

![]() |
Tip |
|---|---|
|
The default layout has the palette area fairly narrow. You can click-and-drag on the bar separating the palette and the arena to adjust the width. |
As mentioned above, the task0_gui_rc
sets up the path and performs the
appropriate repository get-global commands.
(Note that in this case, all of the available components have
been included, for convenience, whereas in the previous
command-line based procedures, the repository
get-global commands appeared in two different
places.)
At this point, you've completed the equivalent of the first
three steps in Section 2.1, “A CCA Application in Detail” (as well as
the additional repository get-global commands
in Step 7) or in the rc
file described in Section 2.2, “
Running Ccaffeine Using an rc File
”.
For the remainder of this procedure, each step will be functionally equivalent to the matching step of the command-line based procedures described above. Please refer to those sections for more detailed explanations of what is happening “behind the scenes”.
We will begin by instantiating a drivers.CXXDriver component.
Click-and-drag the component you want from the palette
to the arena. When you release the mouse button in
the arena, a dialog box will pop up prompting you to
name this instance of the component. The default will be the
last part of the component's class name
(i.e. CXXDriver for drivers.CXXDriver) with
a numerical suffix to insure the name is unique. The suffix
starts at 0 and simply counts up according to the number of
instances of that component you've created in that session.
You can, of course, enter any instance name you like, as long
as it is unique across all components in the arena,
but for simplicity, we will always accept the default value in
this Guide.
For the first application, you should instantiate
drivers.CXXDriver,
functions.PiFunction,
integrators.MonteCarlo,
randomgens.RandNumGenerator,
(you may notice some debugging messages in the GUI host terminal window as you do this), and your GUI should look something like this:

![]() |
Tip |
|---|---|
|
You can drag components around the arena to arrange them as suits you -- just click on the black area of the compoment and drag it to the new location. The positions have no bearing on the operation of the GUI or your application. |
The next step is to begin making connections between the ports
of your components. Click-and-release CXXDriver0's
IntegratorPort uses port, then click-and-release
MonteCarlo0's IntegratorPort provides port and a
red line should be drawn between the two:

![]() |
Tip |
|---|---|
|
If you hover the cursor over a particular port on a component,
a “tool tip” box will pop up with the port's name
and type based on the arguments to the Also notice that when you hover over a particular port (either uses or provides), matching ports of the opposite type (either provides or uses) will be highlighted. |
![]() |
Note |
|---|---|
|
You can move components around even after their ports are connected -- the connections will automatically rearrange. There is no harm in connections crossing each other, nor in connections passing behind other components (though of course they may make it harder to interpret the “wiring diagram” correctly). |
Complete the first application by making the following connections:
CXXDriver0's IntegratorPort to
MonteCarlo0's IntegratorPort
MonteCarlo0's FunctionPort to
PiFunction0's FunctionPort
MonteCarlo0's RandomGeneratorPort to
RandNumGenerator0's RandomGeneratorPort.
At this point, your GUI should look something like:

The application is now fully assembled and is ready to run. If
you click-and-release the GoPort button on the
CXXDriver0 component, you should see the result appear in
the Ccaffeine host terminal, “Value =
3.141449” and the message
“##specific go command
successful” in the GUI host terminal.
Next, we're going to use some of the other components to assemble a different application using the
integrators.Midpoint and
functions.CubeFunction
components. Since they're already in the palette, you can instantiate them in the same way as Step 4.

![]() |
Tip |
|---|---|
|
As we've mentioned, wiring diagrams can become hard to interpret when they become cluttered, as is the case with the screen shot above. To help interpret the diagram, remember the following:
|
Next, we break the port connections we don't need so we can
reconnect to the new components. Right-click on the
IntegratorPort (either the user or the provider)
and a dialog box will pop up asking you to confirm that you want
to break the connection. You will need to break the following
connections:
CXXDriver0's IntegratorPort to
MonteCarlo0's IntegratorPort
MonteCarlo0's FunctionPort to
PiFunction0's FunctionPort
The fact that MonteCarlo0 remains connected to
RandNumGenerator0 is immaterial because neither component will be
used in the remainder of this exercise.
Assemble the new application by making the following connections:
CXXDriver0's IntegratorPort to
Midpoint0's IntegratorPort
Midpoint0's FunctionPort to
PiFunction0's FunctionPort

Click-and-release the GoPort button on the
CXXDriver0 component, you should see the result appear in
the Ccaffeine host terminal, “Value =
3.141553” and the message
“##specific go command
successful” in the GUI host
terminal.
Finally, create a third application by replacing PiFunction0
with CubeFunction0. When you click on the GoPort you
should get “Value =
0.250010” in the Ccaffeine host terminal.

To politely exit the GUI, select → . This will terminate both the GUI and the backend ccafe-client sessions.
![]() |
Tip |
|---|---|
|
If you've used the GUI to setup and start a long-running simulation, and you don't want to leave the GUI running continuously, you can use the → option to close the GUI but leave the backend running. However it is currently impossible to reattach to a running session. |
There are a couple of other features of the GUI and its interaction with the Ccaffeine backend that are worth mentioning.
The rc file used in conjunction with a GUI session
need not be limited to path and
repository get-global commands -- it is
possible to include all Ccaffeine commands, such as in the
script of Section 2.2, “
Running Ccaffeine Using an rc File
”. The GUI will
display all instantiated components, and all connections
between their ports. However, the GUI has no mechanism to
place the components intelligently in the
arena, so it just puts them all on top of each other.
You can, of course, drag them into more reasonable positions.
It is possible to save the visual state of the GUI in a
“.bld” file using the
or button. The .bld file can be loaded
into the GUI and replayed by launching it with the
--buildFile
option.
file.bld
The syntax of the .bld file is similar to that of the
rc file, but they are not
interchangeable. The .bld file can contain commands to
instantiate and destroy components and to connect and
disconnect ports, as well as commands to move components
within the arena, and it can only be interpreted by
the GUI. The path and repository
get-global commands must always be in the rc
file, which is interpreted only by the Ccaffeine backend. Also,
Ccaffeine itself does not understand the movement commands of
the .bld file.