[kepler-dev] event queuing on input ports

[ian.brown at hsbcib.com]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20071114/bb13e0bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: de_check.patch
Type: application/octet-stream
Size: 2815 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20071114/bb13e0bd/attachment.obj>