[kepler-users] token matching mixup due to unmatched boolean switches

[Tirath Ramdas]

Hi all,

FYI this was fixed by getting the latest version of the Nimrod  
director and actors, and the following steps were taken:

1) The PN Director was replaced with the Nimrod Director.
2) The DE Director was inserted into all composite actors.
3) The parameter createNewTags was crated on the Ramp actor, and it's  
value set to 1.

This workflow now behaves as required.

-tirath


On 16/10/2009, at 12:13 PM, Colin Enticott wrote:

> Hi Tirath,
>
> Yes, you'll have to tag the tokens so the environment knows to match
> them. You will need to add a new parameter to the source actor called
> "createNewTags" as type ptolemy.data.expr.SingletonParameter (yes,
> very messy, but I now have an actor that will do it) and set it to
> "true". When that actor sends a token, each one will be individually
> tagged. If you want anything thing else such as reordering, you'll
> need to update the version of the director. Let me know.
>
> Also, if some of those actors can run simultaneously within different
> threads, let me know. You just have to add another parameter for most
> actors, but I'm just sorting out some issues in another thread with
> Edward (mainly about composite actors).
>
> Regards,
> Colin
>
> 2009/10/16 Tirath Ramdas <tramdas at oci.uzh.ch>:
>> Hi Colin,
>>
>> I just gave it a shot (with the exact same workflow, except that  
>> the PN
>> Director is replaced by the Nimrod Director) and unfortunately  
>> things still
>> don't work as I would like. Not only are the results incorrect,  
>> they tend to
>> alternate between two outcomes every time I run the workflow.
>>
>> Note that this is with the workflow here:
>>>>>
>>>>> http://pastebin.com/m2faecfb3
>>
>>
>> Most of the time the results look like this:
>> {1, 0}
>> {2, 1}
>> {3, 2}
>> {4, 3}
>> {5, 4}
>> {7, 5}
>> {8, 6}
>> {9, 7}
>>
>> Sometimes the results look like this (PN Director does the same):
>> {0, 0}
>> {1, 1}
>> {2, 2}
>> {3, 3}
>> {4, 4}
>> {6, 5}
>> {7, 6}
>> {8, 7}
>> {9, 8}
>>
>> Recall the desired result:
>>>>>
>>>>> {0, 0}
>>>>> {1, 1}
>>>>> {2, 2}
>>>>> {3, 3}
>>>>> {4, 4}
>>>>> {6, 6} <- desired result
>>>>> {7, 7} <-
>>>>> {8, 8} <-
>>>>> {9, 9} <-
>>
>>
>> The TDA idea is a very nice one, and in theory I can see it should  
>> have
>> worked, so it must just be an implementation/bug issue? Perhaps the  
>> workflow
>> has to be modified to suit the TDA Director? I'm not sure how  
>> though, it's a
>> pretty simple workflow...
>>
>> One caveat: my version of the TDA director is not very recent, when  
>> you have
>> time could you give it a try with your most recent version?
>>
>> regards,
>> -tirath
>>
>>
>>
>>
>> On 16/10/2009, at 3:18 AM, Colin Enticott wrote:
>>
>>> Hi Tirath,
>>>
>>> You could also use the TDA/NimrodK director that does token tagging
>>> and matching. But, as you know, it is a separate download.
>>>
>>> Regards,
>>> Colin
>>>
>>> 2009/10/16 Edward A. Lee <eal at eecs.berkeley.edu>:
>>>>
>>>> The problem here is that you have an implicit notion of time,
>>>> and that notion is absent in PN.
>>>>
>>>> I suggest using the SR director.
>>>>
>>>> Edward
>>>>
>>>>
>>>> Tirath Ramdas wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I have a situation which I have been able to address in a  
>>>>> "kludgy" way,
>>>>> but I wonder if there may be a better way, so I am presenting the
>>>>> problem
>>>>> and my proposed solution here for your critique and counter- 
>>>>> suggestions.
>>>>> I
>>>>> am sure it's a situation that many others have encountered. This  
>>>>> is with
>>>>> the
>>>>> PN director: I'm not sure how, if at all, the DDF director might  
>>>>> help.
>>>>> Anyway, here goes...
>>>>>
>>>>> THE PROBLEM:
>>>>>
>>>>> Let's say I have a single source of data that has to go through 3
>>>>> actors:
>>>>> A, B, and C. They are laid out in a fork/join configuration. The
>>>>> DataSource
>>>>> goes to A and B, and the outputs from those two actors go to C.  
>>>>> In dot
>>>>> notation, this is what my business logic graph looks like:
>>>>>
>>>>> DataSource -> TaskA;
>>>>> DataSource -> TaskB;
>>>>> TaskA -> TaskC;
>>>>> TaskB -> TaskC;
>>>>>
>>>>> This is a trivial workflow. But now, I want to make my TaskA  
>>>>> actor more
>>>>> sophisticated and detect failures in the computation (I mean  
>>>>> business
>>>>> logic
>>>>> failures - not the kind of thing that can be fixed by re- 
>>>>> execution). I
>>>>> will
>>>>> include in TaskA a boolean switch to detect successful jobs and  
>>>>> push
>>>>> tokens
>>>>> to the output port only when they are good. But the important  
>>>>> thing is
>>>>> that
>>>>> one bad piece of data should not stop the workflow: the rest of  
>>>>> the data
>>>>> gets processed as usual.
>>>>>
>>>>> The problem is, TaskB never knows when one of TaskA's jobs  
>>>>> fails, and it
>>>>> dutifully pushes all of it's tokens through. As a result, TaskC  
>>>>> gets
>>>>> mixed
>>>>> up tokens.
>>>>>
>>>>> A contrived but indicative example: let's say my DataSource is a  
>>>>> Ramp
>>>>> producing 1 to 9, TaskB is simply an expression that pushes all  
>>>>> tokens
>>>>> through, and TaskA has an "error condition" where a token value  
>>>>> "5" is
>>>>> considered an error and routed to the error port instead of the  
>>>>> normal
>>>>> output port. Task C just merges both it's inputs into a 2- 
>>>>> element array.
>>>>> A
>>>>> sample Kepler workflow is here:http://pastebin.com/m2faecfb3
>>>>>
>>>>> What happens is this:
>>>>>
>>>>> {0, 0}
>>>>> {1, 1}
>>>>> {2, 2}
>>>>> {3, 3}
>>>>> {4, 4}
>>>>> {6, 5} <- problem starts here
>>>>> {7, 6} <-
>>>>> {8, 7} <-
>>>>> {9, 8} <-
>>>>>
>>>>> What I want to see is this:
>>>>>
>>>>> {0, 0}
>>>>> {1, 1}
>>>>> {2, 2}
>>>>> {3, 3}
>>>>> {4, 4}
>>>>> {6, 6} <- desired result
>>>>> {7, 7} <-
>>>>> {8, 8} <-
>>>>> {9, 9} <-
>>>>>
>>>>> MY KLUDGE:
>>>>>
>>>>> I hacked around this simply by passing all of TaskB's results  
>>>>> through
>>>>> "passthrough" ports in TaskA, so that TaskA's condition checking  
>>>>> can be
>>>>> effectively applied to TaskB's results as well. This is ugly and
>>>>> seriously
>>>>> detracts from the business process flow that I want to express.
>>>>>
>>>>> I don't want to make TaskC responsible for doing TaskB's error  
>>>>> checking:
>>>>> what if my TaskC is a very generic actor? In practice TaskB's
>>>>> error-checking
>>>>> is highly application-specific (grep-ing the output of a  
>>>>> computational
>>>>> chemistry legacy app).
>>>>>
>>>>> However, I did consider a more generic approach to exception  
>>>>> handling
>>>>> that
>>>>> would in fact place the burden on TaskC: I considered the  
>>>>> possibility of
>>>>> mandating that every actor must output a record which contains the
>>>>> output
>>>>> data and also a "predication" [1] field. The predication field  
>>>>> indicates
>>>>> when the data is valid. Any actor receiving tokens only proceeds  
>>>>> with
>>>>> the
>>>>> computation if the predication fields on all it's inputs are set  
>>>>> to
>>>>> valid;
>>>>> if even one is invalid, the whole lot gets routed to an error  
>>>>> bin, but
>>>>> the
>>>>> next lot gets processed as though nothing went wrong. Also I  
>>>>> vaguely
>>>>> recall
>>>>> reading that some other workflow engine does something like this.
>>>>> Anyway, I
>>>>> did not proceed with this yet because it sounds like a non-trivial
>>>>> amount of
>>>>> work to modify all the actors I use to adhere to this behavior.
>>>>>
>>>>> Any other ideas?
>>>>>
>>>>> regards,
>>>>> -tirath
>>>>>
>>>>> [1] Borrowing the word "predication" from Intel's Itanium branch
>>>>> misprediction handling, not sure who they borrowed the term from.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Colin
>>
>>
>
>
>
> -- 
> Colin