Edward and Christopher covered most of the differences between Kepler and Ptolemy, especially with respect to the 1.0 release. The current development version of Kepler that is leading to our 2.0 release includes a number of additional major differences, some of which include:<br>
<br> 1) Module-based extension<br> - a system for extending Kepler through a well-defined module API that allows people and projects to extend and package changes to the underlying system, the GUI, the actors, etc. and the published modules can be loaded at runtime from within the new (and evolving) Module Manager.<br>
<br> 2) A searchable remote repository that can store new actors, workflows, and their associated metadata in order for people to publish and share their work<br><br> 3) A new module for provenance store that allows tracking of the state of the workflow executions and the data that passes among actors during a run, and a workflow run manager that uses the provenance store to create a searchable database of prior executions.<br>
<br> 4) A GUI report designer module that allows construction of nicely formatted reports that organize the outputs and other information about a workflow run. After execution, these reports can then be viewed in Kepler and can create PDF versions of the report (which we use for a web-based reporting system).<br>
<br> 5) Extensions to the remote repository and the packaging format (KAR) to allow workflow execution runs from provenance to be exported into an archive format, uploaded to the repository, and shared with colleagues. <br>
<br> 6) A smenatic tagging module that extends and generalizes the existing ontology system in Kepler to provide a more intuitive GUI for tagging actors, workflows, reports, and runs with semantic tags drawn from OWL ontologies.<br>
<br>Kepler benefits tremendously from the powerful execution engine and infrastructure that is provided by ptolemy, but over time we've been improving Kepler by developing features and actors that help streamline the process of scientific analysis. Hope this helps in your quest for information. When Kepler 2.0 is updated we'll update the FAQ entry describing the additional differences between Kepler and Ptolemy.<br>
<br>Matt<br><br><div class="gmail_quote">On Mon, Oct 19, 2009 at 6:42 AM, Christopher Brooks <span dir="ltr"><<a href="mailto:cxh@eecs.berkeley.edu" target="_blank">cxh@eecs.berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Tom,<br>
<br>
See the Kepler/CORE mission statement at<br>
<a href="https://kepler-project.org/users/projects-using-kepler-1/kepler-core-vision-and-mission" target="_blank">https://kepler-project.org/users/projects-using-kepler-1/kepler-core-vision-and-mission</a><br>
<br>
For information about the differences between Kepler and Ptolemy,<br>
<a href="http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler" target="_blank">http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler</a> says<br>
--start--<br>
<br>
Ptolemy (<a href="http://ptolemy.eecs.berkeley.edu" target="_blank">http://ptolemy.eecs.berkeley.edu</a>) and The Kepler Project (<a href="http://www.kepler-project.org/" target="_blank">http://www.kepler-project.org/</a>)<br>
are two separate projects. The Kepler Project FAQ says<br>
<br>
What is the difference between Kepler and Ptolemy?<br>
Roughly speaking, Ptolemy aims at modeling concurrent systems,<br>
studying system models, various models of computation, etc. as explained above.<br>
In constrast, Kepler aims at execution of scientific workflows (by end users<br>
and/or workflow engineers), inheriting modeling and design capabilities including<br>
the Vergil GUI and workflow scheduling and execution capabilities from Ptolemy.<br>
<br>
How does Kepler extend Ptolemy?<br>
Kepler extensions to Ptolemy include an ever increasing number of components<br>
(called actors in Ptolemy terminology) aimed particularly at scientific applications,<br>
e.g., for remote data and metadata access, data transformations, data analysis,<br>
interfacing with legacy applications, web service invocation and deployment,<br>
provenance tracking, etc. Target application areas include bioinformatics, cheminformatics,<br>
ecoinformatics, and geoinformatics workflows among others.<br>
<br>
Kepler also inherits from Ptolemy the actor-oriented modeling paradigm that<br>
separates workflow components from the overall workflow orchestration<br>
(via so-called directors), making components more easily reusable. Through actor-oriented<br>
and hierarchical modeling features built into Ptolemy, Kepler scientific workflows can<br>
operate at very different level of granularity, from low-level "plumbing workflows"<br>
that explictely move data around, start and monitor remote jobs, etc. to high-level<br>
"conceptual workflows" that interlink complex, domain specific data analysis steps.<br>
<br>
Concerning using Ptolemy actors within Kepler, Norbert Podhorszki writes:<br>
<br>
If you find a Ptolemy actor useful, just remember its class name<br>
(e.g. ptolemy.actor.lib.Ramp). In Kepler, "Tools/Instantiate Component" menu allows<br>
you to type in the class name, which will put an actor instance on your canvas just as<br>
dragging one from the actor tree.<br>
<br>
The ptolemy jar is stored in the kepler.jar, so you have access to any Ptolemy<br>
actors and directors.<br>
<br>
If you want to use a director not in Kepler tree, you have to use the<br>
"Tools/Instantiate Attribute" menu. I use it to get a DDF director frequently<br>
(class ptolemy.domains.ddf.kernel.DDFDirector).<br>
<br>
I suppose, you can create a kar file for any ptolemy actor just as for<br>
kepler actors, if you want to add some of them into the Kepler actor tree.<br>
--end--<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. In my experimentation, the system appears stable and reasonably efficient.<br>
</blockquote></blockquote>
> But my testing has been on the trivial side. Does the system scale well to<br>
> large sophisticated image processing workflows with many levels of composite<br>
> actors and high volume data streams?<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
There are applications with tens of thousands of actors.<br>
They require machines with quite a bit of memory, however.<br>
</blockquote>
<br></div>
Ptolemy has JAI and JMF actors. There are also actors that pass around Java Image<br>
types and standard matrices of doubles or integers. Using the correct token<br>
type is the key to good performance. Better performance can be had by avoiding<br>
lots of model based conversions between data formats and instead sticking with one token<br>
type and writing a few Java actors. Using a performance analysis tool can help.<br>
<br>
We are working on various performance improvements that would generate Java code<br>
for hierarchical sub-components, but this work is still in progress.<div><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
6. I note you have an actor that provides access to MATLAB. <br>
</blockquote></blockquote>
>> Can the same actor be used for Octave? (see <a href="http://www.gnu.org/software/octave/" target="_blank">http://www.gnu.org/software/octave/</a>).<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don't think there is anything standard about the API to MATLAB, so<br>
I doubt it... But I'm sure one could create an actor for Octave.<br>
</blockquote>
<br></div>
The Matlab actor will not work with Octave. Last time I tried to use Octave<br>
(probably 10+ years ago), getting Octave to work required Fortran?. If there<br>
is an C API to Octave, then the Matlab actor could be used as an template.<br>
<br>
There are several ways to interface to external programs:<br>
1) Use an Exec actor to open a pipe to the external program and pass data.<br>
This has problems in that it might start up the program each time the actor<br>
fires. Also, passing data can be tricky<br>
2) If there is a C interface, then write a custom actor that sends and receives<br>
data<br>
3) Micheal Wetter of LBNL has created a system that uses sockets to connect<br>
to external programs. This requires writing a little C code, but seems to<br>
be easier than #2 above. However, I'm not sure if the interface in this method<br>
is as rich as #2.<br>
<br>
To me, the biggest issues with interfacing to other programs are:<br>
- Handling different datatypes can be tricky.<br>
- Handling error conditions is tricky.<br>
<br>
<br>
_Christopher<div><div></div><div><br>
<br>
Edward A. Lee wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
In addition to the packaging and actor library differences,<br>
Kepler also has significant UI extensions and infrastructure<br>
for searching actor libraries...<br>
<br>
In some cases, there is functionality that overlaps... E.g.,<br>
Kepler has an ontology mechanism, but we have built a somewhat<br>
different ontology mechanism into Ptolemy II. This is part of<br>
a research project on scalable model engineering. Eventually<br>
I hope these two mechanisms will merge, but I can't say with<br>
confidence that that will ever happen...<br>
<br>
Anything else I'm missing?<br>
<br>
Edward<br>
<br>
Thomas M. Parris wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edward,<br>
<br>
Thanks for your prompt reply (over the weekend!). I'll take a closer look<br>
at the FIR actor and the source for the R and MATLAB wrappers. I've also<br>
been focussing on the Kepler documentation instead of the Ptolemy II<br>
doumentation. It looks like I need to switch focus and look more<br>
specifically at Ptolemy II docs. Is it fair to say the major difference<br>
between Kepler and Ptolemy II is packaging and the actor library?<br>
<br>
-- Tom<br>
<br>
<br>
_______________________________________________<br>
Kepler-users mailing list<br>
<a href="mailto:Kepler-users@kepler-project.org" target="_blank">Kepler-users@kepler-project.org</a><br>
<a href="http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users" target="_blank">http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a><br>
</blockquote>
_______________________________________________<br>
Kepler-users mailing list<br>
<a href="mailto:Kepler-users@kepler-project.org" target="_blank">Kepler-users@kepler-project.org</a><br>
<a href="http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users" target="_blank">http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a><br>
</blockquote>
<br></div></div><font color="#888888">
-- <br>
Christopher Brooks (cxh at eecs berkeley edu) University of California<br>
CHESS Executive Director US Mail: 337 Cory Hall<br>
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774<br>
ph: 510.643.9841 fax:510.642.2718 (Office: 545Q Cory)<br>
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480</font><div><div></div><div><br>
_______________________________________________<br>
Kepler-users mailing list<br>
<a href="mailto:Kepler-users@kepler-project.org" target="_blank">Kepler-users@kepler-project.org</a><br>
<a href="http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users" target="_blank">http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a><br>
</div></div></blockquote></div><br>