[kepler-dev] modeling question about producing f(A, x), f(A, y)...
Norbert Podhorszki
pnorbert at cs.ucdavis.edu
Mon Aug 6 17:00:47 PDT 2007
Some follow up FYI.
On Fri, 3 Aug 2007, Norbert Podhorszki wrote:
> a1
> A1 ---------------> ------ ..., f(a1,z), f(a1,y), f(a1,x)
> | A3 | -------------------------------->
> A2 ---------------> ------
> ...,z,y,x
Part 1.
-------
Actually, if we are sure that 'a1' is produced before A3 is executed,
under PN-DDF combo, we can use the infamous VariableSetter actor to set a
Parameter and then use that parameter in A3.
In order to let it work as we expect, we have to turn of the 'delayed'
flag in VariableSetter, thus forcing the update of the parameter
immediately.
Although the use of VariableSetter can make the PN workflow
indeterministic in general, if we take care of not executing A3 too early,
it is safe. And by far the most simple way of composing workflows for this
problem.
myParameter: "unknown"
a1
A1 --------> VariableSetter /* to set myParameter */
------ ..., f(a1,z), f(a1,y), f(a1,x)
A2 ---------------> | A3 | -------------------------------->
...,z,y,x ------
part 2.
-------
It would be nice if VariableSetter would emit the input token as an
output token after its firing. This would allow us to have more control
enforcing the order of execution and eliminate dangerous concurrency.
Then the workflow above would look like this:
myParameter: "unknown"
a1
A1 --------> VariableSetter /* to set myParameter */
|
----------------
| ------ ..., f(a1,z), f(a1,y), f(a1,x)
--> A2 -----------> | A3 | -------------------------------->
...,z,y,x ------
Can we ask Ptolemy people to extend the VariableSetter with an output
port?
part 3.
-------
Although I knew this solution originally before posting the problem, I
do not use it because my workflow also has SDF subworkflows at deeper
levels (4th levels) wherever it can be used for the sake of performance.
However, if I have VariableSetters in the workflow with 'delayed off',
Ptolemy cannot compute the static schedules for the (completely unrelated)
SDF subworkflows. Can someone comment on this why and whether we can do
anything to avoid it?
Here I have two options. One is to eliminate all SDF stuff from the
workflow and replace it with DDF. The other is to create a simple actor
which makes a shared Hashtable (to completely piss off Edward and all
honest people aligning themselves with computational models :-( allowing
me to "put" labeled tokens into it and to "get" them anywhere in the
workflow without having connections. Although I made the latter, I dislike
it because using Parameters in the workflow is way much more convenient
and thus preferable for "future, non-expert" users of Kepler.
This is the situation at this moment.
Best regards
Norbert
More information about the Kepler-dev
mailing list