2.3. Using the GUI Front-End to Ccaffeine

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.

2.3.1. Running Ccaffeine with the GUI

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 --port 3314 \ 1
             --ccafe-rc rc_file \ 2

1

This tells Ccaffeine the port number to expect the GUI to connect to. Typically, it can be any port number between 1025 and 65535 that doesn't conflict with another application wanting to use the same port. In this Guide, we will use port 3314, but you can change this if it is problematic.

[Warning] Warning

If you're working in a setting in which there may be more than one person using Ccaffeine on the same system, you must choose different ports, or you will conflict! Choosing anything besides the default port, the chances of a conflict are small.

If you're participating in an organized CCA tutorial, we'll assign you a port number to use for the GUI as part of your account information as a simple way to insure there are no conflicts. Please use your assigned port number in this case!

2

An rc file is required in order to set the component search path and do the repository get-global commands to load the required components into the palette. In the tutorial, rc files are automatically generated for use with the GUI. They are $TUTORIAL_SRC/components/examples/taskn_gui_rc. You may find it convenient to copy them into your working directory rather than retyping the complete path every time you need to reference them. So for the first exercise, you should copy $TUTORIAL_SRC/components/examples/task0_gui_rc to your working directory and use it as the argument for the --ccafe-rc argument.

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 pOutn (for the stdout stream) and pErrn (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 pOut0 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:

gui.sh

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.

simple-gui.sh

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”.

simple-gui.bat

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] 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 --builderPort 3314 \ 1
        --host localhost 2

1

This tells the GUI which port to use for the connection to Ccaffeine host. In general, it should match the ccafe-client --port option (though when tunneling the connection through ssh, that need not be the case).

2

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 localhost).

[Note] 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] 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] Note

Once the GUI displays on your screen, it may take a few more seconds before it will respond to user actions.

2.3.2. Assembling and Running an Application Using the GUI

  1. 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 --port 3314 --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.

  2. 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:

    
      GUI with components in palette and empty arena

    [Tip] 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.)

  3. 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”.

  4. 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:

    
      GUI with several components instantiated in arena (Step 4)

    [Tip] 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.

  5. 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:

    
      Driver's integrator port connected to integrator's integrator port

    [Tip] 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 addProvidesPort or registerUsesPort calls in the component's setServices method. This can be useful for double checking to make sure you're connecting matching ports.

    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] 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:

    
      Fully connected application (Step 5)

  6. 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.

  7. 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.

    
      Additional components instantiated (Step 7)

    [Tip] 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:

    • Wires” only connect to the sides of ports -- on the left side of provides ports (on the left side of the component), or on the right side of uses ports. Connections are never made to the top or bottom of a component.

    • The GUI's wire-drawing algorithm is aware only of the two components that are being connected. It will make no attempt to avoid other components or other wires. So wires can pass behind components without connecting to any of their ports, and wires may overlap.

    • If you're still uncertain how to interpret the connections try rearranging the components slightly. Connections attached to the component will follow as you drag it around, but others not associated with that component will remain unchanged.

  8. 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.

    [Note] Note

    Step 7 and Step 8 could have been done in either order.

  9. Assemble the new application by making the following connections:

    • CXXDriver0's IntegratorPort to Midpoint0's IntegratorPort

    • Midpoint0's FunctionPort to PiFunction0's FunctionPort

    
      Another application, with extraneous components still in arena
      (Step 9)

    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.

  10. 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.

    
      A third application, with extraneous components still in arena
      (Step 10)

  11. To politely exit the GUI, select FileQuit. This will terminate both the GUI and the backend ccafe-client sessions.

    [Tip] 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 FileDetach option to close the GUI but leave the backend running. However it is currently impossible to reattach to a running session.

2.3.3. Notes on More Advanced Usage of the GUI

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 Save or Save As... button. The .bld file can be loaded into the GUI and replayed by launching it with the --buildFile file.bld option.

    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.