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

[Norbert Podhorszki]

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
      ----------------------------------