Hi Rich,
The Kepler provenance framework captures all the data
transferred between actors. By default, this is written
to an SQL database, but you could send it elsewhere. For
more information about the provenance framework, see:
https://code.kepler-project.org/code/kepler/trunk/modules/provenance
/docs/provenance.pdf
Also, the Reporting suite creates reports of workflow
results including the data transferred between actors. See:
https://code.kepler-project.org/code/kepler/trunk/modules/reporting/docs/reporting.pdf
--dan
On 1/10/14 9:44 AM, Rich Morin wrote:
On Jan 10, 2014, at 09:20, Christopher Brooks wrote:
My responses are below.
Thanks!
The following questions have to do with the inter-actor "piping"
and best practices for command debugging and optimization.
Q: Can I add recording and/or archiving as attributes to a pipe?
So, for example, could I tell Kepler to turn on recording for
particular pipes, without needing to explicitly add an actor?
(This could be used for "tracing" key paths in an app.)
I don't know of an actor that has access to pipes. ...
Perhaps I should have said "plumbing". I'm referring to the usual
communication channels used by Kepler/Ptolemy actors, not to Unix
named pipes, etc.
There was a talk at the PII meeting about hanging attributes on
connections. I was wondering if something like this could be used
to enable archiving or analysis of the transmitted data, etc.
-r
--
http://www.cfcl.com/rdm Rich Morin [email protected]
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841
Software system design, development, and documentation
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
