| Lines 6-635 were replaced by lines 6-33 |
| - \\__1)__ Importance: 1, votes: 4 |
| - \\__Use Case Name:__ Detached Execution |
| - |
| - \\__Version:__ |
| - |
| - \\__Summary:__ |
| - * User would like the ability to begin a Kepler workflow with laptop, detach/disconnect, and reconnect at a later time to check on execution status. Notifications may optionally be sent when workflow execution completes (how notifications will be sent will likely be configured in the workflow). |
| - * Ability to launch from the command line in batch mode. |
| - * Ability to re-attach to running job to check its progress. |
| - * User would also like to check status, and stop workflow jobs via a web interface. |
| - |
| - |
| - \\__Preconditions:__ |
| - * Have a complete workflow assembled. |
| - * Distributed execution system has been built and running on an accessible server. |
| - * Server has all software that the workflow requires (eg R, Matlab, etc) |
| - * Other users are not currently connected to workflow with Write access. |
| - |
| - \\__Triggers:__ |
| - * User launches job in batch mode. It will automatically detach at this point. |
| - * From gui, user selects "detach". |
| - |
| - |
| - \\__Basic course of events:__ |
| - * User designs workflow that includes notification system (eg uses Email Sender actor). |
| - * User identifies server(s) and establishes connection. |
| - * User executes workflow in either batch or gui mode (when workflow has graphical output, batch mode can handle this, eg ignore it, or write it out to eg pdfs) |
| - * When workflow completes it sends notification. |
| - * While job is running, user can reconnect to server and check status, alter settings, stop job or retrieve results. |
| - |
| - \\__Alternative paths:__ |
| - * Instead of using Kepler, view progress on a webpage. |
| - * Ability to suspend workflow without detaching from it |
| - |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - ---- |
| - \\__2)__Importance: 2 |
| - \\__Use Case Name__: Smart Reruns |
| - \\__Version:__ |
| - \\__Preconditions:__ |
| - |
| - User has designed a workflow that specifies: |
| - # conditions under which a complete rerun of workflow should occur when user executes workflow (eg "if data sources I have marked have changed, a smart rerun cannot occur") |
| - # which intermediary derived data products to save for use by smart reruns |
| - |
| - \\__Summary:__ |
| - |
| - Users want the ability to rerun certain workflows in a "smart" way, that is, without regenerating intermediary derived data products if the source data (and hence the derived data for non-stochastic models) have not changed. Some intermediate derived data products take a very long time to produce, hence it is beneficial to skip their generation when possible. |
| - |
| - \\__Triggers:__ |
| - |
| - User executes a workflow that uses Smart Rerun features and all Smart Rerun criteria have been met. |
| - |
| - \\__Basic course of events:__ |
| - |
| - Workflow developer designs a workflow that makes use of Smart Rerun components. |
| - |
| - Upon execution of this workflow, Smart Rerun components check to see if their input data sources have changed (possibly the user can also specify conditions which must also be met). If these data sources have changed (or are being used for the first time), components (re)produce derived data products and save those that are marked as Smart Rerun derived data products. If data sources have not changed, and previously saved derived data products exist, a Smart Rerun can occur reusing these existing products. Special considerations for stochastic systems must be taken into account in the design of this usecase (do we allow Smart Reruns for certain stochastic models?). |
| - |
| - |
| - \\__Alternative paths:__ |
| - |
| - * It is possible a user would also like the ability to do a Smart Rerun even if Smart Rerun criteria are not met, ie they might want to ignore the fact that data sources have changed and reuse existing derived data products to test something else. |
| - |
| - \\__Postconditions:__ |
| - |
| - Intermediary derived data products produced by Smart Rerun actors are saved. |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - ---- |
| - \\__3)__Importance: 2 |
| - \\__Use Case Name__: Optional archiving of intermediate derived datasets. |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users want to be able to save intermediate derived datasets. |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ This usecase can be seen as required by the "Smart Rerun", "Manage a group of model runs", and "Archive a complete end to end run" usecases |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__4)__Importance: 1, votes: 5 |
| - \\__Use Case Name__: Archive a complete end to end run ("publication ready archive") |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like the ability to create a "publication ready archive"--an archive that contains the Kepler workflow, all required inputs (data sources like database tables are included), and all produced output. For example, at the completion of a study, a user can produce this archive and submit it (or a link to it) alongside their paper to peers and journals. |
| - |
| - \\__Preconditions:__ |
| - |
| - * User has created workflow that contains everything needed (eg data sources). |
| - * User documents any external software the workflow requires |
| - |
| - \\__Triggers:__ |
| - |
| - User exports workflow |
| - |
| - \\__Basic course of events:__ |
| - |
| - User creates a workflow. User turns on "publication ready archive" mode. User runs workflow, and exports to an archive at completion. |
| - |
| - \\__Alternative paths:__ |
| - |
| - User uses features from "Smart Rerun", "Manage a group of model runs", and "save intermediate derived data products" usecase (ie a special "publication ready archive" mode might not be required). |
| - |
| - \\__Postconditions:__ |
| - |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - |
| - A specific "publication ready archive" option would not be required if requirements for usecases mentioned in Alt Paths are implemented. |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__5)__Importance: 2 |
| - \\__Use Case Name__: Database actor option: Snapshot |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like the ability to use a database (or more likely simply some data from a table in a database) in two ways. |
| - # User can download a snapshot of the database or data from database and in all consecutive workflow runs, operate on this data snapshot |
| - # Each time workflow is run, the (potentially dynamic) database is queried and the resulting response is used. |
| - |
| - \\__Preconditions:__ |
| - |
| - * User has setup a workflow that uses a database actor |
| - * User has configured database actor to either snapshot or realtime mode. |
| - |
| - \\__Triggers:__ |
| - |
| - Workflow containing database actor is run. |
| - |
| - \\__Basic course of events:__ |
| - |
| - |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - |
| - If Snapshot feature is used, data snapshot is saved. |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - |
| - ---- |
| - \\__6)__Importance: 2 |
| - \\__Use Case Name__: Actor specific annotations (gui linked) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to be able to produce annotations that are visually closely coupled with actors. When an actor is dragged around the campus, if it has an associated annotation, this annotation moves alongside it. This does not require a graphical link (eg line or box) that groups the two, but this could be done. |
| - |
| - \\__Preconditions:__ |
| - |
| - A component has been created with which to associate an annotation. |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - User creates a component and chooses to create an associated annotation for it. |
| - |
| - \\__Alternative paths:__ |
| - |
| - Another way to approach this would be mouseover "alt text" popups. |
| - |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__7)__Importance: 1, votes: 2 |
| - \\__Use Case Name__: Actor for Data-Merge for specific product |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users want the ability to easily merge many different data sources into one. For example, in the REAP terrestrial case study users might want to merge a) data in differently formatted excel and text files b) data from near-realtime streams and c) data pulled from an archive. Users want this process to convert units if needs be. |
| - |
| - |
| - \\__Preconditions:__ |
| - |
| - An instance of data-merge component has been created with inputs connected to desired data sources. |
| - |
| - \\__Triggers:__ |
| - |
| - User executes workflow. |
| - |
| - \\__Basic course of events:__ |
| - |
| - User creates an instance of data-merge component and connects its input ports to desired data sources. |
| - User specifies certain properties in the data-merge actor regarding how to merge data (eg how to convert units, if interpolation or decimation should occur, which differently names fields correspond, etc). Depending on how complex the data-merge actor becomes, it may have to require user interaction. |
| - |
| - \\__Alternative paths:__ |
| - |
| - User merges data themselves :) |
| - |
| - \\__Postconditions:__ |
| - |
| - Merged derived source data product is produced--and potentially saved. |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__8)__Importance: 2 |
| - \\__Use Case Name__: Integrate database actors |
| - \\__Version:__ |
| - \\__Summary:__ make database actors more consistent. |
| - |
| - DatabaseQuery actor has different output ports than metacat database actors -- users would like these actors to be more consistent. |
| - Users would also like to be able to view a database and its tables with this integrated actor. |
| - |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__9)__Importance: 1 |
| - \\__Use Case Name__: Event Notification Monitoring system |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to be able to design workflows that send out alerts when certain criteria are met. |
| - |
| - Users would typically like these kinds of workflows to run automatically and periodically on a cron or cron-like system that easy to setup. |
| - |
| - Examples: |
| - * monitor rainfall thresholds |
| - * light monitoring, eg if ambient light < ground level light, send email. |
| - * monitor if animals go outside a certain radius or bounding box |
| - * monitor the proximity of different animals, eg mating events |
| - |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - |
| - * A specified threshold or condition has been reached. |
| - * A certain type of error has occurred |
| - |
| - \\__Basic course of events:__ |
| - |
| - * User designs an event monitoring workflow and sets it to run indefinitely or periodically |
| - * Workflow continously or periodically runs. workflow checks if certain conditions are true. |
| - * If a condition is met, a notification is sent via channel specified in workflow (eg email) |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__12)__Importance: 1, votes: 1 |
| - \\__Use Case Name__: Manage a group of model runs |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to be able to design a workflow that allows for the management a group of model runs. |
| - This means: |
| - * allowing user to easily define multi-dimensional parameter sweep |
| - * allowing user to change course by redefining the parameter sweep part-way through execution |
| - * saving all important aspects of each run (a log of parameters used, changes made, data products produced (including graphs)) |
| - * grouping sets of products produced in an understandable way (eg legend of params used on each graph, listed in metadata of products produced, output files grouped by name or directories, etc) |
| - * user might like ability to specify which intermediate data products are saved. |
| - * ability to read parameter space from a file that user has configured |
| - * allow for "irregular sweeps" |
| - * allow random parameters |
| - |
| - This might be accomplished with a parameter sweep actor. |
| - |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - User develops workflow that includes a Parameter Sweep component. The input port(s) of this component are connected to parameters or parameter source(s) like a text file. |
| - |
| - \\__Alternative paths:__ |
| - |
| - User designs a workflow that uses and changes (existing) Parameter components. |
| - |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__13)__ Importance: 1, votes: 1 |
| - \\__Use Case Name__: Workflows need to accommodate sub-workflows that operate at different frequencies |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__14)__Importance: 1, votes: 4 |
| - \\__Use Case Name__: Tutorial or Wizard for wrapping external programs |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to easily wrap an external program in Kepler. By "wrap" we mean create a simple workflow that consists of being able to run an external program that has already been developed, eg a C or Fortran program. |
| - |
| - Users would like either or both of the following: |
| - # an instruction set / tutorial for easily "wrapping" an external program into a workflow in Kepler |
| - # a wizard inside Kepler that takes them through the steps of producing this workflow. |
| - |
| - \\__Preconditions:__ |
| - |
| - Working external program has already been written. |
| - |
| - \\__Triggers:__ |
| - |
| - User runs wizard or user opens tutorial. |
| - |
| - \\__Basic course of events:__ |
| - |
| - User executes wizard inside Kepler, points it at their external program, and configures any required settings via the wizard. |
| - |
| - \\__Alternative paths:__ |
| - |
| - User reads tutorial that explains how to "wrap" external programs and builds the workflow. |
| - |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__15)__Importance: 1 |
| - \\__Use Case Name__: Easily create and share workflows and actors |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users want an easy way to create and share workflows with others. This means making sure exporting, emailing, and importing workflows is painless, or the submission of workflows/actors to a repository that others can import from is painless. |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - # User1 creates component or workflow. |
| - # User1 exports or publishes component or workflow. |
| - # User2 imports component or workflow. |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__17)__Importance: 3 |
| - \\__Use Case Name__: facilitate peer review process |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__18)__Importance: 3 |
| - \\__Use Case Name__: Use Kepler as a teaching tool |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to use Kepler as a teaching tool. This means adding features such as: |
| - * ability to "lock" certain components away from students |
| - * improving Kepler's animation (eg show parameters as they change) so live demos are more expressive |
| - * improving Kepler's error messages. |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ There was a lock of discussion on how to "lock" things. with ideas ranging from simply changing the icon or color of the component to signify the user should not touch it, to more difficult to circumvent restrictions like a password. |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__19)__Importance: 3 |
| - \\__Use Case Name__: Ecological Actors |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like a set of components to do common ecological functions (ie mean or sum...) over temporal and spatial scales |
| - |
| - \\__Preconditions:__ |
| - |
| - If ecologists want to create some of these: improvements to workflow and component submission to repository process have been made. |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - User makes use of new ecological components in library as they would any other. |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__20)__Importance: 2 |
| - \\__Use Case Name__: FakeData Generator Actor(s) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like a set of FakeData Generator Actors appropriate to the REAP Case Studies. A FakeData actor should produce data in the same way a real data source would. For example, a "FakeData_CR800_Temperature" Actor might produce a datastream of temperature data at 1 "sample" per minute. The actual data in the datastream should be indecipherable from a real temperature stream coming out of a Campbell CR800 datalogger deployed in the field. Somewhere in the metadata however, a FakeData Generator Actor should clearly identify itself (as being fake). |
| - |
| - \\__Preconditions:__ |
| - |
| - Depending on how exactly we wish to simulate certain datalogger datastreams, these specs need to be available during the development of this/these actor(s). |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - |
| - * User drags actor to canvas like any other data source. |
| - * User configures actor to specify it as a certain type of data source (eg Campbell temperature stream) with sampling characteristics. |
| - |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| - \\__21)__Importance: 3 |
| - \\__Use Case Name__: 3d plots |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to be able to produce 3d plots with Kepler. |
| - (ggobi, gnuplot, java3d ?) |
| - |
| - \\__Preconditions:__ |
| - |
| - 3d visualization software is installed on user's machine. |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__Use Case Name__: Iterator wrapper actor |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like an Iterator Actor that iterates a workflow, or parts of a workflow in a smart way. See Paramater Sweep Usecase. |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| - \\__22)__Importance: 3 |
| - \\__Use Case Name__: Markov Chain Monte Carlo (mcmc) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Allow this different technique for running models. Can not use if model is stochastic. |
| - |
| - \\__Preconditions:__ |
| - |
| - An understanding of mcmc. :) |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ (see winbugs and R2WinBUGS) |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - ---- |
| - \\__23)__Importance: 2 |
| - \\__Use Case Name__: Breakpoints |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like to be able to add breakpoints in a workflow. When a breakpoint is reached, workflow execution is paused or stopped. Users would also like breakpoints to be conditional, eg a breakpoint might only pause or stop execution once a certain condition (like equilibrium) has been reached. |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - ---- |
| - \\__24)__Importance: 2 |
| - \\__Use Case Name__: Debugging |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like an easy way to debug workflows. Some ideas on this: a special debug output port on all actors; or a specific debug actor (most workflow developers make extensive use of the display actor to verify output after each step as they build workflows--new users might not think of this, an actor named or tagged Debug might be of use) |
| - |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| + | Usecase Name | Importance | Number Votes |
| + | [Archive a complete end to end run ("publication ready archive")|Usecase Publication ready archive]| 1 | 5 |
| + | [Tutorial or Wizard for wrapping external programs|Usecase Tutorial or Wizard for wrapping external programs] | 1 | 4 |
| + | [Detached Execution|Usecase Detached Execution]| 1 | 4 |
| + | [Actor for Data-Merge for specific product|Usecase Actor for Data-Merge for specific product] | 1 | 2 |
| + | [Manage a group of model runs|Usecase Manage a group of model runs] | 1 | 1 |
| + | Workflows need to accommodate sub-workflows that operate at different frequencies | 1 | 1 |
| + | [Event Notification Monitoring system|Usecase Event Notification Monitoring system] | 1 | |
| + | [Easily create and share workflows and actors|Usecase Easily create and share workflows and actors] | 1 | |
| + | [Improve component search. |Usecase Improve component search. ] | 1 | |
| + | [Improved error messages.|Usecase Improved error messages.] | 1 | |
| + | [Smart Reruns|Usecase Smart Reruns] | 2 | |
| + | [Optional archiving of intermediate derived datasets. |Usecase Optional archiving of intermediate derived datasets. ] | 2 | |
| + | [Database actor option: Snapshot|Usecase Database actor Snapshot option] | 2 | |
| + | [Actor specific annotations (gui linked)|Usecase Actor specific annotations (gui linked)] | 2 | |
| + | [Integrate database actors|Usecase Integrate database actors] | 2 | |
| + | [Search through workflow for a certain type of actor|Usecase Search through workflow for a certain type of actor] | 2 | |
| + | [FakeData Generator Actor(s)|Usecase FakeData Generator Actor(s)] | 2 | |
| + | [Breakpoints|Usecase Breakpoints] | 2 | |
| + | [Debugging|Usecase Debugging] | 2 | |
| + | [Disable actors|Usecase Disable actors] | 2 | |
| + | [Different workflow view|Usecase Different workflow view] | 3 | |
| + | [facilitate peer review process |Usecase facilitate peer review process ] | 3 | |
| + | [Use Kepler as a teaching tool|Usecase Use Kepler as a teaching tool] | 3 | |
| + | [Ecological Actors|Usecase Ecological Actors] | 3 | |
| + | [3d plots|Usecase 3d plots] | 3 | |
| + | [Markov Chain Monte Carlo (mcmc) |Usecase Markov Chain Monte Carlo (mcmc) ] | 3 | |
| + | Iterator wrapper actor | | |
