[kepler-users] Greetings/newbie questions about Kepler

[Timothy McPhillips]

Hi Tom,

I don't know if anyone else will agree with the following, but I  
thought I'd share a few of my thoughts about (a) some distinctions  
between Ptolemy and Kepler, (b) how these distinctions derive from the  
differences between a system model and a scientific workflow, and (c)  
what the implications of these differences are for what sorts of  
features one might expect to find in Kepler but not in Ptolemy, etc.

The way I think about it, Ptolemy primarily (with lots of exceptions)  
is meant for building models of systems (e.g, an embedded computer  
system, a network of interacting compute nodes, a dynamic system  
describable by differential equations, etc), either for gaining  
insight into those systems, or for prototyping implementations of  
those systems.   Such models may read data from files or acquire data  
from the environment, but the questions one asks of a Ptolemy model  
often is not about the data, but instead about the behavior and  
properties of the modeled system itself.  The questions explored can  
also be about the properties of the model of computation employed in a  
system model.

Kepler, on the other hand, is meant primarily (again, with many  
exceptions) for automating scientific workflows.  A scientific  
workflow typically represents a set of computational tasks that a  
scientist wants to carry out on scientific data, with the purpose of  
gaining insight about the data or about the system from which the data  
was gathered. So while it can be useful to consider a scientific  
workflow also to be a model (of the tasks to be carried out on a data  
set, of the flow of data and control between these tasks, etc), the  
ultimate purpose of creating a scientific workflow typically is not to  
gain insight about the workflow, but about the data input to the  
workflow.

Of course Ptolemy can be used to automate scientific workflows, and  
Kepler can be used to model systems. Nevertheless, these differences  
have plenty of implications for what features might be important to  
Kepler users but less so for Ptolemy users, and vice versa.

Because Ptolemy models generally are meant to yield insight into the  
model, I would guess that a Ptolemy user is more likely to want to see  
the key aspects of the system model represented graphically on the  
canvas.  The director placed on the canvas represents the model of  
computation used by the rest of the model.  The flow of all data,  
signals, and other information often are represented as explicit  
connections between model components.  Anything expected to  
significantly affect the behavior or performance of the model probably  
is going to be represented explicitly as part of the model, or clearly  
indicated by the director or another component placed on the canvas.

Kepler end users, on the other hand, often are going to be much more  
interested in being able to quickly assemble a set of tasks to be  
invoked on some input data, and to efficiently execute those tasks.   
It would not at all bother many Kepler users to find that after a  
Kepler upgrade, say, certain portions of their (unmodified) workflows  
suddenly run much more quickly due to the inclusion of a new caching  
system that transparently captures intermediate data products during  
workflow runs and makes those data products automatically available to  
future workflow runs such that redundant computations are not  
performed.   I expect that a Ptolemy user more likely would prefer to  
see such a cache represented graphically in each model, and might not  
want to find the behavior of their models suddenly changing due to a  
quietly introduced, behind-the-scenes data caching scheme.

There are plenty of counterexamples to everything I've said (and  
grossly oversimplified) above because both Ptolemy and Kepler are both  
incredibly flexible, and the communities using each (or both) are  
extremely diverse.  In the past I have used Ptolemy to automate  
scientific workflows for gaining insight into scientific data, and  
currently I use Kepler primarily to study alternative paradigms for  
modeling and automating scientific workflows (in other words, I more  
often study scientific workflows than the data they operate on).

The way I see it, the shared heritage and ongoing transfer of insight  
and features both directions between Ptolemy and Kepler make each much  
more powerful and useful.  But the two products do remain distinct for  
good reasons.

Cheers,

Tim

On Oct 20, 2009, at 6:34 AM, Thomas M. Parris wrote:

> Edward, Matt, Christopher,
>
> Thank you all.  I have found this exchange to be very usefull.
>
> The road map that Matt provides for V2 is very helpful and helps
> differentiate the two efforts.  It also encourages me to subscribe  
> to the
> developers list to get a better sense of how the project is  
> evolving.  The
> two pieces missing from that discussion is a sense of timeline and  
> backwards
> compatability.  Kepler 1.0.0 was released in May 2008?  When will we  
> likely
> see 2.0.0 (May 2010?).  Will all workflows developed under 1.0.0 work
> unmodified under 2.0.0?
>
> Chistopher decribes the procedures for adding Ptolemy II actors and  
> methods
> to Kepler.  Also very helpful (and something I will certainly be  
> doing in
> the near future).  But it does raise an interesting question.   
> Clearly, the
> Kepler team is making some decisions about which elements of Ptolemy  
> II
> merit a priori inclusion in a user interface for "scientific  
> workflows"
> whereas others do not.  I must admit that I find this  
> differentiation to be
> confusing.  Is there an explicit set of criteria?
>
> Edward makes the distinction between a building and its foundation.   
> So
> perhaps I can draw the following analogy.  Potelemy II is to Kepler  
> as is
> Gecko to Firefox.  Rather obvious now that I look at it, but perhaps  
> a point
> that could me made more clearly in the 2.0.0 documentation.
>
> I'm off to investigate some of the specifics.  That probably means  
> silence
> from me for at least a few days.
>
> -- Tom
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20091020/5b3550a9/attachment.html>