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

[Norbert Podhorszki]

Hi Stephen,

We would like to have the first one.
The model on the top is PN, but the sub-model, which actually 
would use the value (before tokens are coming) is DDF.
We have many parameters (coming from a config file) used in that 
sub-model, but now we face a parameter which is created during the run 
(but before calling that DDF model).

Does it hold for PN-DDF what you are saying for hierachical SDF?

Thanks
Norbert



On Fri, 3 Aug 2007, Stephen Neuendorffer wrote:

> This is exactly what 'PortParameters' attempt to solve. It accepts input
> on a port, and uses it to set a parameter value.  The key question is:
> when does the setting of the parameter occur?  If you want it to
> occur exactly once, and before all other input tokens are processed,
> then
> PN doesn't have a good way of specifying this (although modal models
> could be used instead of a PortParameter).  If you want to have it
> occur every N tokens, then we have a very good way of specifying it:
> hierarchical SDF: SDF guarantees that port parameters are read exactly
> once before the beginning of each iteration.
> If you want to have it occur irregularly, then use PSDF,
> pass the number of tokens to be processed with the current A as a
> second port parameter, and set the iterationCount of the PSDF
> director to be the value of the parameter.
>
> In SDF (and SDF-derived domains) there are very good solutions here.
> In PN, you have to explicitly coding the behavior you want.
> The only good way of doing that in Ptolemy is a modal model, or perhaps
> CAL...
>
> Steve
>
>> -----Original Message-----
>> From: owner-ptolemy-hackers at bennett.EECS.Berkeley.EDU
>> [mailto:owner-ptolemy-hackers at bennett.EECS.Berkeley.EDU] On
>> Behalf Of Norbert Podhorszki
>> Sent: Friday, August 03, 2007 2:01 PM
>> To: Kepler-Dev
>> Cc: ptolemy-hackers at bennett.EECS.Berkeley.EDU; Bruce Char
>> Subject: Re: [kepler-dev] modeling question about producing
>> f(A, x), f(A, y)...
>>
>> Hi Bertram,
>>
>> A3 should pair a1 with as many tokens on the second stream as
>> many comes there. There is no a2 in this problem.
>>
>> For you Bertram, the specification is the following: we need
>> something which could be used practically as an input
>> parameter, but the value is determined during the workflow
>> run (and only once). In scripting languages, we use variables
>> for this purpose.
>>
>> Having no good way of using variables in workflows, we have
>> to wire up everything to deliver the value from the producer
>> to all consumers (as many times they intend to use it).
>>
>> Of course, you cannot make a Java actor work this way. It
>> would be blocked on the first input port. But if you look at
>> the PN solution I attached earlier, a composite workflow can
>> make as many repetition of the single token as many token
>> arrives on the second:
>>
>>          a1
>> A1 ---------------> -----  a1,a1,a1
>>                      | R | ----------|
>>                  |-> -----           |-> ------
>> ...f(a1,z),f(a1,y),f(a1,x)
>>                  |                       | A3 |
>> -------------------------->
>> A2 -----------------------------------> ------
>>        ...,z,y,x
>>
>>
>> Norbert
>>
>>
>> On Fri, 3 Aug 2007, Bertram Ludaescher wrote:
>>
>>> 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
>>>
>>>
>>
>> --------------------------------------------------------------
>> --------------
>> Posted to the ptolemy-hackers mailing list.  Please send
>> administrative mail for this list to:
>> ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>>
>>
>
>


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