[kepler-users] Sequence to Array problem

Tue Jan 26 19:56:10 PST 2010

Dear Tomasz,

Sorry about the delay responding... Email avalanche...

I think that DDFDirector must have a rather subtle bug.
First, it defines a notion of an iteration that is questionable
because it relies on the idea that a firing may be "deferrable."
Your first example (and this one) shows that it could decide
that a firing is deferrable, but it would be wrong because if
it were to fire the actor, it would no longer be deferrable.
This introduces nondeterminism in the sense that you can ask
a model to run for N iterations and get different results on
successive runs.

Second, for some reason, it stops executing if any actor that it
thinks should be able to fire doesn't. This is what is happening,
I think, when the firingCountLimit is reached for the Const actor.
The director chooses to stop executing altogether...  I'm not sure
why...

Edward

On 1/25/10 2:40 AM, Tomasz Żok wrote:
> Dear Edward and Christopher,
>
> Thank you for such deep analysis. I thought about it and it is true, that
> data-dependent workflows will not always work with
> "requiredFiringsPerIteration" parameter set.
>
> Please take a look at another example I am sending. It is a modification of
> "sta-3.xml" you have sent before. My changes:
> - I added some processing of the array output by Sequence to Array actor
> - it checks if the length of this array is odd or even, and displays it in a
> different window accordingly
>
> If I leave firingCountLimit as NONE in the Constant actor, then the workflow
> never finishes.
>
> If I change firingCountLimit to 1, then interesting things happen. The workflow
> works alright as long as I leave Constant value unchanged OR I add new
> elements to the array in Constant. However, if I remove anything from the
> Constant, then it fails to show any output again.
>
> It seems that DDF director notices the change of Constant, but only if the
> change makes an array longer.
>
> Best regards,
> Tomek
>
>
> On piątek 22 stycznia 2010 at 17:43:43 Edward A. Lee wrote:
>> To add to this:
>>
>> The issue is that what it means to run a DDF model for one iteration
>> is rather tricky. In the model provided, it just so happened that
>> model stopped executing before the sink actors were fired.
>> Hence the lack of output.
>>
>> When using the DDF director, it is best to control the iteration
>> explicitly by adding a parameter called requiredFiringsPerIteration
>> to your sink actors. If you set the value to 1, then one iteration
>> of the model should include one firing of the sink actor.
>>
>> There are, I believe, two bugs in the DDF director.
>>
>> 1) It appears that even with requiredFiringsPerIteration set
>> to 1 in a sink actor, the iteration may stop before the sink
>> actor is fired.  This seems to be caused in Tomasz' example
>> by the firingCountLimit parameter of the Const actor.
>>
>> 2) Without requiredFiringsPerIteration being set, it seems
>> that what constitutes an iteration is nondeterminate when there
>> are actors whose consumption pattern is data dependent.
>>
>> These are both probably quite difficult to fix. The theory
>> tells us that any definition an iteration (a finite, determinate
>> computation) in DDF will be undecidable. Our DDF director
>> implementation is rather clever in defining an iteration that
>> is guaranteed to be finite, but not guaranteed to be determinate.
>> I conjecture that no strategy can guarantee both...
>>
>> So the problem may be a fundamental one, rather than a software bug.
>> PhD thesis topic anyone?
>>
>> Edward
>>
>> On 1/22/10 8:19 AM, Christopher Brooks wrote:
>>> Hi Tomasz,
>>> Edward Lee took a look at this problem yesterday and it appears
>>> to be an bug in the DDFDirector.
>>>
>>> We did fix one bug in SequenceToArray where the arrayLength
>>> PortParameter now has arrayLength.update() called in prefire()
>>> instead of fire(). The way PortParameters work is that
>>> update() should be called once during an iteration.
>>>
>>> Getting back to DDFDirector, it looks like what is happening
>>> is that when the Const actor is analyzed to determine if it
>>> is ready to fire, the downstream actors are also analyzed
>>> to see if they are enabled. Unfortunately, it seems like
>>> if the enabled state of the downstream actors is changing,
>>> then the DDFDirector is not noticing?
>>>
>>> It also appears that in this context the notion of an iteration
>>> in DDFDirector is not deterministic in this implementation.
>>> We think that the issue has to do with firingCountLimit in the Const
>>> being set to 1.
>>>
>>> The attached model is similar to your sta-1.xml except with
>>> the following changes:
>>> * Const.firingCountLimit was changed from 1 to NONE
>>> * In the Display actor, a parameter named requiredFiringsPerIteration
>>> was added and set to 1
>>> * I set the number of iterations in the DDFDirector to 1.
>>> The model now behaves properly when the Const is changed from
>>> three elements to two.
>>>
>>> I have a test case checked in to the nightly build that illustrates
>>> the problem, so eventually it should be fixed.
>>>
>>> _Christopher
>>>
>>> On 1/20/10 12:36 PM, Christopher Brooks wrote:
>>>> Hi Tomasz,
>>>> The problem is that in sta-1.xml, after running with
>>>> an array of three elements, and then changing the Const
>>>> to an array of two elements, the SequenceToArray actor
>>>> is not being enabled.
>>>>
>>>> The issue seems to be with the arrayLength PortParameter
>>>> of SequenceToArray.
>>>>
>>>> If I animate execution, then I can see that the ArrayToSequence
>>>> is firing before the ArrayLength actor. It appears that
>>>> the SequenceToArray actor is not being enabled after the arrayLength
>>>> gets updated.
>>>>
>>>> I tried to create a regular model that illustrated this bug
>>>> by using a Sequence actor instead of a Const but could not replicate
>>>> the bug.
>>>>
>>>> However, I was able to create a Tcl test that reads in the model, runs
>>>> it, checks the output, changes the Const and then runs the model again.
>>>>
>>>> I've included the Ptolemy model that is used in the test. Note that
>>>> the model writes to stdout for testing purposes.
>>>>
>>>> I'll see if I can take a look at this with Edward.
>>>>
>>>> _Christopher
>>>>
>>>> On 1/20/10 2:17 AM, Tomasz Żok wrote:
>>>>> Hi,
>>>>>
>>>>> I'd also like to post the simplest example workflows showing exactly
>>>>> when this
>>>>> bug occurs.
>>>>>
>>>>> In the attachment you can find sta-1.xml and sta-2.xml. Both workflows
>>>>> produce
>>>>> an array out of set of tokens.
>>>>>
>>>>> Please load sta-1.xml and run it. You will see {"aaa", "bbb", "ccc"}
>>>>> in the
>>>>> display. Right next after this execution, delete the token "ccc" from
>>>>> the
>>>>> input data and run the workflow. You will get no output at all.
>>>>>
>>>>> In the sta-2.xml do just the same steps. But in this case, you will
>>>>> correctly
>>>>> see {"aaa", "bbb", "ccc"} and later {"aaa", "bbb"}
>>>>>
>>>>> Both workflows should act the same, but only the second one works
>>>>>
>>>>> Regards,
>>>>> Tomek
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kepler-users mailing list
>>>>> Kepler-users at kepler-project.org
>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>>>
>>>> _______________________________________________
>>>> Kepler-users mailing list
>>>> Kepler-users at kepler-project.org
>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>>
>>> _______________________________________________
>>> Kepler-users mailing list
>>> Kepler-users at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 364 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100126/c2b2b3b2/attachment.vcf>