<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Tom,<div><br></div><div>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.</div><div><br></div><div>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 <i>gaining insight into those system</i>s, 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 t<i>he behavior and properties of the modeled system itself</i>. The questions explored can also be about the properties of the model of computation employed in a system model. </div><div><br></div><div>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 <i>gaining</i> <i>insight about the data </i>or<i> </i>about<i> the system from which the data was gathered</i>. So while it can be useful to consider a scientific workflow also to be a <i>model</i> (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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Tim</div><div><br></div><div><div>On Oct 20, 2009, at 6:34 AM, Thomas M. Parris wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Edward, Matt, Christopher,<br><br>Thank you all. I have found this exchange to be very usefull. <br><br>The road map that Matt provides for V2 is very helpful and helps<br>differentiate the two efforts. It also encourages me to subscribe to the<br>developers list to get a better sense of how the project is evolving. The<br>two pieces missing from that discussion is a sense of timeline and backwards<br>compatability. Kepler 1.0.0 was released in May 2008? When will we likely<br>see 2.0.0 (May 2010?). Will all workflows developed under 1.0.0 work<br>unmodified under 2.0.0?<br><br>Chistopher decribes the procedures for adding Ptolemy II actors and methods<br>to Kepler. Also very helpful (and something I will certainly be doing in<br>the near future). But it does raise an interesting question. Clearly, the<br>Kepler team is making some decisions about which elements of Ptolemy II<br>merit a priori inclusion in a user interface for "scientific workflows"<br>whereas others do not. I must admit that I find this differentiation to be<br>confusing. Is there an explicit set of criteria?<br><br>Edward makes the distinction between a building and its foundation. So<br>perhaps I can draw the following analogy. Potelemy II is to Kepler as is<br>Gecko to Firefox. Rather obvious now that I look at it, but perhaps a point<br>that could me made more clearly in the 2.0.0 documentation.<br><br>I'm off to investigate some of the specifics. That probably means silence<br>from me for at least a few days.<br><br>-- Tom<br><br>_______________________________________________<br>Kepler-users mailing list<br><a href="mailto:Kepler-users@kepler-project.org">Kepler-users@kepler-project.org</a><br>http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users<br></div></blockquote></div><br></body></html>