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

[Timothy McPhillips]

Hi Norbert,

Just out of curiosity, by what metric do you consider a collection- 
oriented (or any other) solution "heavy"?  Number of actors?  Number  
of actor interconnections?  Number of tokens passed?  Fraction of CPU  
time spent managing data? Time spent composing the workflow?

Cheers,

Tim


On Aug 3, 2007, at 11:45 AM, 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
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
> kepler-dev