Team:Berkeley Software/KeplerTutorial
From 2009.igem.org
Line 22: | Line 22: | ||
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. These actors are supervised by the "director", which keeps track of when to run each actor.<br> | 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. These actors are supervised by the "director", which keeps track of when to run each actor.<br> | ||
- | [[Image:BerkeleySoftware_KeplerActorList.png|Some | + | [[Image:BerkeleySoftware_KeplerActorList.png|thumb|<span style="font-family: Georgia, serif;">Some Sample Kepler Actors</span>]] |
- | [[Image:BerkeleySoftware_KeplerDirectors.png|Common | + | [[Image:BerkeleySoftware_KeplerDirectors.png|thumb|<span style="font-family: Georgia, serif;">Common Kepler Directors</span>]] |
Revision as of 23:52, 21 October 2009
Kepler Tutorial
Introduction
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 Clotho connection. 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 [http://kepler-project.org/ Kepler Project Website].
Components
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. These actors are supervised by the "director", which keeps track of when to run each actor.
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 details instruction of installing and making workflows: Kepler Documentation
Assembly Workflows
As described in the Kepler project page, this workflow get assembly information from Clotho's Algorithm Manager, and output files for the liquid handling robot and human instructions.
Actor list
A. OpenClothoConnection: connect Kepler to Clotho with RMI Tool running. If succeeds, this actor output the connection with Clotho RMI methods so the next actors can use.
B. GetAssemblyGraph & GetString: get data from Clotho, such as the algorithm graph or some debugging string. These actors output either genetic Object data or special structure such as the assembly information
C. GraphProcessing: process the assembly information, check & prepare data for further options
D. DialogOption: antibiotic choices, either at runtime or user provides a choice in the parameter before workflow runs
E. AutomationScheduler
F. Constant: Input for the stage number. This is only a constant number, easy for future modification such as putting an array here for multiple stages in one run
G. OneStageProcessing: Making the files from the assembly graph and the choices of stage and antibiotic
H. Display actors: use to display information, such as finish getting data and the names of created files
Clotho RMI Connection
One of the key challenge for biology tool development is how to effectively share and cooperate. This year we strengthen the possibility of connection between multiple software. In particular, the Clotho platform from last year and Kepler can connect and send data through the remore interface with Java RMI. This RMI connection will guarantee Clotho and Kepler to talk to any Java software that import the same interface.
In assembly workflow, we made actor that open a Clotho RMI connection and actors that read data from Clotho tools. These actors supports genetic data objects and has 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;
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, it is needed to to have some user options such as antibiotic choices or stage choices. The problem can get user to select a choice at runtime, along with displaying some information about the current data so the user knows better about about their preferred choice. However, if the same workflow needs to run multiple times, with almost the same data and choice, repeatedly asks the user to click similar things each time is not ideal. With Kepler workflow, we present two ways of giving users' choices, either at runtime or parameters before workflow starts. For example, the Dialog Option actor for antibiotic choices will pop up a dialog for choosing antibiotic at runtime, after Kepler get the assembly graph and gives explanation about what is inside each choices. Alternatively, experienced user can also input an integer as antibiotic index before clicking run, and the workflow will run to finish without pause & pop-up dialog. These dual ways of user options enable the workflow to run as a regular tool step-by-step choices and a fully automated process for a large numbers of similar run, even without graphic interface.
The stage chooser also is designed with flexibility, allowing user to further modify the stage choice by putting an array of stage numbers, or another dialog option.
Demo