[kepler-dev] modeling question about producing f(A, x), f(A, y)...

[Bertram Ludaescher]

Hi Norbert:

Your graph below seems to be underspecified. How would A3 know how
many times to pair a1 with x,y,z,... etc?

(see also the questions re. this by Daniel and Carlos).

Can you pls clarify?

cheers

Bertram



On 8/3/07, Norbert Podhorszki <npodhorszki at ucdavis.edu> wrote:
>
> Close :-)
>
>           a1
>   A1 ---------------> ------  ..., f(a1,z), f(a1,y), f(a1,x)
>                       | A3 | -------------------------------->
>   A2 ---------------> ------
>         ...,z,y,x
>
>
> Norbert
>
> On Fri, 3 Aug 2007, Daniel Zinn wrote:
>
> > Hi Norbert,
> >
> > ok, then maybe I don't understand the problem well enough. Let me give it
> > another shot:
> >
> > in PN:
> >
> > A1 ---------------> A3
> >    \---> A2 ----->
> >
> > A1 produces A which is branched and sent to A2 and A3.
> > A2 just produces x,y,z,... from A
> > A3 first reads from the A1 port and stores the A
> >   then reads from the second port only and does its thing
> >
> > Daniel
> >
> >
> > On Friday 03 August 2007 11:45, Norbert Podhorszki wrote:
> >> Hi Daniel,
> >>
> >> Thanks for the idea.
> >> You have generalized the problem here, because for us, A is just one
> >> single token (a1 in your example).
> >>
> >> The collection-oriented modelling seems to be a bit heavy weight solution
> >> in the sense, that if we start from a Constant with single firing and a
> >> Ramp to generate a stream of tokens, it seems to be a lot of work to make
> >> it a collection oriented workflow, isn't it?
> >>
> >> Thanks
> >> Norbert
> >>
> >> On Fri, 3 Aug 2007, Daniel Zinn wrote:
> >>> 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
> >
> > --
> > "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
> > _______________________________________________
> > Kepler-dev mailing list
> > Kepler-dev at ecoinformatics.org
> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
>
>
>       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
>       ----------------------------------
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>


-- 
Bertram Ludaescher, Assoc. Professor
Dept of Computer Science & Genome Center
University of California, Davis
One Shields Avenue, Davis, CA 95616
Ph: (530) 754-8576
ludaesch at ucdavis.edu