[kepler-dev] event queuing on input ports

[Edward A. Lee]

Ian,

This is a very subtle issue, but I'm not crazy about solving
it with a DE Director parameter... I suspect very few users would
have any idea what this parameter means.

Your illustrative example is very good, and would make a good
part of tutorial material on DE.  But it seems to me both variants
of your model (with and without the sampler) are in fact valid
and useful.  The semantics of the Expression actor is that it needs
a token on each input port to calculate the expression. In your
upper model, each token is used once, which is exactly what I
would expect. In the bottom model, each token may be used multiple
times, and in fact, it's hard to tell from looking at the model
how many times it will be used. Suppose for example that the
tokens are dollar additions to a bank account, and that the delay
represents that some wire transfers take a circuitous route.
Then the bottom model would be distinctly wrong, as it would
result in the amount being credited to a accounting depending
on the time delay of the wire transfer!

Your director parameter suggests that the upper model is wrong.
This is misleading, I think... Both models have their uses.

I think this problem is better solved with more careful
tutorial material on the DE semantics...

Edward


At 03:37 AM 11/14/2007, ian.brown at hsbcib.com wrote:

>Looking into implementing this, I discovered that there is some very similar code in the DEDirector commented out. That code cleared the stale tokens at the end of every firing - it's not really what I want because I want to be alerted of an issue with the model rafter than having the framework silently 'correct it' - I guess that's why it is commented out. 
>
>I adapted the code a bit so that instead of silently clearing the receivers, it triggers an exception if it finds a token on any of them. Also, because not every model wants this, and also because you probably only want the overhead of the test during development and not in production, I also added a parameter which controls whether the test is performed or not. 
>
>A patch to the DE Director is attached - I would be interested in any feedback. 
>
>Ian 
>
>
>
>ian.brown at hsbcib.com 
>
>13/11/2007 18:37 
>Mail Size: 27869 
>To
>kepler-dev at ecoinformatics.org 
>cc
>Subject
>[kepler-dev] event queuing on input ports 
>Entity
>Investment Banking Europe - IBEU 
>
>
>
>
>
>We've recently tracked down a subtle logic problem in one of our models. We had a strategy expressed as a modal model which we then re-implemented as a python actor for increased speed. The issue we had was that the results were different even though the logic looked the same. 
>We finally tracked it down to the fact that tokens queue up on the python actor's input ports whilst they don't on the modal model. 
>There's nothing wrong with this - it's just that we didn't realise that was what was happening until we investigated a bit more deeply. To illustrate the issue, I have attached a simple model which just uses a clock, a delay and an expression actor. In order for it to work as we expect, we need a sampler actor too. This would be a good example to have in the documentation because as a user, the detail of how this worked was not clear. 
>
>Now, generally, in my domain, if events queue between director firings then it is almost certainly an error in the model. What I would like to do is to be able to check during a test run that all of the input ports for all of my actors are empty between director firings. In other words, they should be empty when the model time is incremented but they can have tokens when the microstep is incremented. In this case, the check would flag that the top model in the example was in error. 
>I could just add some code to the DE Director to check for this condition, but that does not seem very elegant. I was thinking that it could be possible to add a model attribute (like the dependency highlighter) which would perform this check if it was present. Does that sound like a good idea? Does anyone have any better suggestions for implementation and has anyone solved any similar analysis problems? 
>One reason for using Ptolemy / Kepler for this work rather than pure Java is the theoretical ability to better check the 'correctness' of the models ... and this is a step in that direction. 
>
>Ian 
>
>
>
>************************************************************
>HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest.
>
>HSBC Bank plc
>Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
>Registered in England - Number 14259
>Authorised and regulated by the Financial Services Authority.
>************************************************************
>
>
>SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. 
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------ 
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html