[kepler-dev] modeling question about producing f(A, x), f(A, y)...
Daniel Zinn
dzinn at ucdavis.edu
Fri Aug 3 11:28:37 PDT 2007
Hi,
(let me try, perhaps this might help)
The problem here is that we need to preserve the dependency between A and
x,y,z... This is a classical use-case for collection-oriented workflows.
You could probably use Tim McPhillips' and Shawn Bowers' collection-oriented
framework to solve this problem. You could send A as meta-data in a
collection that contains x,y,z,.... In the third actor you then just pull the
metadata and the x, ..
You can also emulate a collection by using a workflow with 3 actors in a
pipeline:
A1 --> A2 --> A3
actor one sends a1,a2,a3...
A2 consumes a1 and produces a1, x, y, z, ..., a2, x, y, z
A3's behavior depends on the type of what is coming in:
if input == ai => store ai in a local variable for later
else (input is one of x,y,z,...) => compute f(ai, input) and output
result (with or without context)
PS:
In a collection oriented / tree-type enabled workflow where inner nodes also
can contain data, you could do something like that:
Let the three actors be
A1 --> A2 --> A3
A1 produces data of type A* (that is a list of As)
A2 produces data of type A[X*] (that is to each A, also contains a
list of x,y,z...
as a new sub collection)
A3 then has a 'read scope' of A=>a[ X=>x ]
A3's action then uses a and x.
Daniel
On Friday 03 August 2007 11:00, Norbert Podhorszki wrote:
> Hi,
>
> I have no working solution for the following problem described by Bruce
> Char, see below. Any working idea/example would be appreciated.
> I also have the same problem currently and am craving for a good solution.
>
> Thanks
> Norbert
>
> Norbert Podhorszki
> ------------------------------------
> University of California, Davis
> Department of Computer Science
> 1 Shields Ave, 2236 Kemper Hall
> Davis, CA 95616
> (530) 752-5076
> pnorbert at cs.ucdavis.edu
> ----------------------------------
>
> ---------- Forwarded message ----------
> Date: Fri, 03 Aug 2007 13:14:59 -0400
> From: Bruce Char <bchar at cs.drexel.edu>
>
> That seemed to do it. What does this setting do?
>
> I am beginning at least to understand that I don't know how to "solve"
> certain kinds of situations. Here's the latest:
>
> actor 1 issues a token, call it A. This gets split and sent to multiple
> branches of the work flow as a trigger.
> One of the branches contains actor 2. This issues one or more tokens (we
> don't know exactly how many ahead of time). Call them x, y, z, ...
>
> We want to create an actor that is downstream of actors 1 and 2. Its job
> is to create tokens that are a function of the output of actors 1 and 2:
> f(A,x), f(A,y), ...
>
> Actor 1 in real life is the job submitter, which produces the location of
> the working directory, actor 2 is a filter of the file watcher. It's going
> to create file conversion commands that I'll pass to ssh.
>
> I have realized that I can create actors where all input ports have equal
> numbers of tokens going in. But in this case I don't have that. If I
> were in the ordinary programming world I would have actor 1 set a variable
> v, and lower a sync barrier. actor 2 each time it emits a token would
> first check that the sync barrier was down and then emit the token. The
> final actor would refer to the value of v and the input from actor 2 to do
> its work.
>
> However, I realize I don't really know how to set a variable in Kepler! I
> know how to set constants (which won't help since the value of A is unknown
> at start up time). I know how to set expressions (which can fire the same
> number of times as actor 1 fires, which is once). I can imagine that there
> are some kinds of feedback loops that would remember A and then provide it
> each time a token from actor 2 provides a firing signal. I am not really
> sure how to set the latter up, but needing a feedback loop also seems more
> complicated than an ordinary user would want. So I figure that there's
> something in Kepler that can handle this simply but I don't know what it
> is.
>
> Bruce
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--
"The acquisition of wealth is no longer the driving force in our
lives ... we work to better ourselves and the rest of humanity."
reach me at: Jabber:q at n251.fem.tu-ilmenau.de ICQ:79511325
AIM:QN303 Skype:DanielZinn IRC:q at irc.gimp.org
More information about the Kepler-dev
mailing list