[kepler-users] Sequence to Array problem

[Edward A. Lee]

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/20100122/d11aacbc/attachment.vcf>