Team:Berkeley Software/KeplerTutorial


Kepler Tutorial


The Kepler design environment helps scientists design models and perform analysis across a broad range of scientific and engineering disciplines. We were interested in answering the question, "can Kepler be used in synthetic biology efficiently". In order to investigate this more we introduced Kepler into synthetic biology by building a set of new Kepler actors for assembly automation and to provide a remote connection to Clotho. Our goal was to create a set of reusable actors and workflows which in the face of constant change could adapt to reflect the latest lab protocols and design flows. For more information on Kepler we invite you to check out the Kepler Project Website. In addition, much of the work we performed was with the Center for Hybrid Embedded Software Systems (CHESS) as Kepler was born of the Ptolemy Project.


In Kepler, a workflow is built from a collection of process steps that run under the control of a supervisor system.

Those separate steps are called "actors", they are represented as square icons but inside them resides code determining what to run in a "step" of a workflow simulation. A step can be an input/output operation, a computational function, or even another workflow. Actors can support hierarchical construction where composite actors contain multiple primitive actors. These actors are supervised by the "director", which keeps track of when to run each actor.

Some Sample Kepler Actors
Common Kepler Directors - Static DataFlow and Dynamic DataFlow

Kepler comes with a library of available actors for many tasks, and user can always write their custom actors and share.

The online manuals provide detailed instruction for installing and making workflows: Kepler Documentation. We highly recommend those interested read this material as it contains much more detailed descriptions then we will provide here.

Automated Assembly Workflow

Our Automated Assembly Kepler Workflow

As described in the Kepler project page, this workflow receives assembly information from Clotho's Algorithm Manager, and outputs files for the liquid handling robot as well as human readable instructions.

Detailed Actor List

A. OpenClothoConnection: connect Kepler to Clotho while the Clotho RMI Tool is running. If successful, this actor will output the connection with Clotho RMI methods so the next actors can use them.
B. GetAssemblyGraph & GetString: both receive data from Clotho, such as an assembly graph or some debugging information. These actors output either genetic Object data or a special structure such as the assembly information.
C. GraphProcessing: process the assembly information, check & prepare data for further options.
D. DialogOption: allows for users to make antibiotic choices, either at runtime or the user can provide a choice as a parameter before workflow runs.
E. AutomationScheduler
F. Constant: Input for the stage number. This is only a constant number, thus it is easy for future modifications such as using an array so that multiple stages can be specified in one run.
G. OneStageProcessing: Creates the files from an assembly graph, the choice of stage, and antibiotic selection.
H. Display actors: Use to display information, such as when the workflow is finished getting data and the names of created files.

Clotho RMI Connection

One of the key challenges for biology tool development is how to effectively share and cooperate. This year we strengthened the possibility of establishing a connection between Clotho and other software tools. In particular, the Clotho platform and Kepler can connect and send data through the a remote API interface via Java RMI. This RMI connection will guarantee Clotho and Kepler to talk to any Java software that import the same interface.

RMI Connection and Clotho Interaction

In our assembly workflow, we made a custom actor which opens a Clotho RMI connection. We also made actors that read data from Clotho tools. These actors support communication via genetic data objects (for maximum flexibility) and have parameters for tool name and object fields, thus they will work with any future Clotho tools, as long as those tools support Clotho Data API methods.

Clotho RMI interface:

    * Get data from a Clotho tool. The tool must already instantiated in Clotho.
    * Data will be called from the core method getData
    * @param toolName - exact class name in up & lower case of a Clotho tool
    * @param object
    * @param field
    * @return data as Object, need to cast back to the correct class
    * @throws java.rmi.RemoteException
   public Object getData(String toolName, String object, String field) throws RemoteException;
    * Send data to an instantiated Clotho tool.
    * Data will be sent by the core method sendData without operation code
    * @param toolName -exact class name in up & lower case of a  Clotho tool
    * @param object
    * @param field
    * @param data - Data to be sent
    * @throws java.rmi.RemoteException
   public void sendData(String toolName, String object, String field, Object data) throws RemoteException;

"GetString" Actor Interface

This is the configuration of the Kepler actor "GetString". This actor can read data from tools in Clotho and send out a String object to output ports. In the image, we want to read data from the tool "AlgorithmManager", if there are multiple data fields, we can further specify what data we want with the other two parameters.

User Options

In an assembly workflow, we need to to have some user options such as antibiotic selection or stage choices. The problem during a running workflow is to allow the user the ability to select a choice at runtime, along with displaying some information about the current data so the user knows as much as possible about about their preferred choices. However, if the same workflow needs to run multiple times, with almost the same data and choices, repeatedly asking the user to click similar things repeatedly is not ideal. With Kepler workflows, we present two ways of giving users choices, either at runtime or via parameters before workflow starts. For example, the "Dialog Option" actor for antibiotic choices will pop up a dialog for choosing antibiotics at runtime, after Kepler receives the assembly graph and provides an explanation about each choice. Alternatively, experienced users can also input an integer as an antibiotic index before clicking run, and the workflow will run to completion without pause for a pop-up dialog box. These dual ways of presenting user options enable the workflow to run as a regular tool with step-by-step choices and a fully automated process for a large numbers of similar runs, even without graphical interface.

"Dialog Option" Actor Illustration for Antibiotic Selection

The stage chooser also is designed with flexibility in mind, allowing users to further modify the stage choice by putting an array of stage numbers, or another dialog option.


Demo illustrating a Kepler workflow in action.