[kepler-dev] event queuing on input ports

[ian.brown at hsbcib.com]

Edward,
        I fully agree that neither model is 'wrong' and that depending 
upon the problem it may be desired to have one behaviour or the other. 
That's why the commented out code that exists at the moment is certainly 
not the solution. The main issue was that we assumed the semantics were 
different than what they are (our problem, not Ptolemy / Keplers) ... 
having discovered this though, we started wondering how we could stop the 
same situation happening again in the future (especially with a new 
modeller).

My issue is that assuming you have a model where you defiantly do not want 
tokens to persist beyond their firing cycle, there is no easy way to 
detect if the model is correct in that manner. Our models are many layers 
deep (we have composite models nested up to 6 levels deep) and we have a 
lot of these composite models that are re-used across models. Whilst the 
initial design may ensure that the semantics are correct, I need a simple 
way to check that the semantics are what we want at any time in the 
future.

I would be happy with a menu point or something to perform a static 
analysis. Currently, my little addition to the DE Director allows me to 
check the box and run the model with test data. If the exception does not 
fire, I now have some more confidence that it is 'correct' according to my 
semantic definition. I can then uncheck the box and move it into 
production (obviously though some test data first).

Another thought I had was to allow an input port to have a 'transient' 
parameter that you can set in the port parameters dialog. If the port was 
transient then it would be cleared by the DE Director in-between firings. 
That would maybe allow for a cleaner model ... but I don't really like it 
... it hides the issue from the modeller. Throwing the assertion at least 
forces the modeller to understand the semantics of the ports and to use a 
sampler if necessary. Another solution may be to specify the allowed queue 
length for a port and then the director can perform a semantic check to 
make sure that there are not too many tokens on a port (a max length of 
zero would effectively be a transient port).

I'm happy to keep my local mod of course (our local virgil is already 
reasonable modified to add things like save buttons on the toolbar etc). 
I'm interested in discussing the best way to implement such a semantic 
check though.

As a bit of background, our model was looking at the price of a currency 
(this changes 3 or 4 times a second). It was calculating a moving average 
and comparing that with the current price to decide whether to trade (very 
simplified description). The comparison was an expression and the effect 
was that we were comparing the spot price at the start of the window of 
the moving average with the moving average value (the moving average 
effectively was acting as a delay). Because the window was small, this 
effect was not immediately obvious other than that the modal model 
implementation of the trading model made more money than the expression 
based one. It took 2 days of running test data and attaching a lot of 
monitors to finally figure out what the issue was. Given that we are 
dealing with live price data, it is pretty easy for us to define ports 
which should never have stale or queued data - in other words, we can give 
the model some meta-data which will allow an automatic semantic check. 
This is a big bonus over using a traditional language to implement such 
models.

I hope the above makes sense - it's a bit of a brain dump (it's 
approaching the end of the day here in London and it's been a busy day :) 
)

Ian




"Edward A. Lee" <eal at eecs.berkeley.edu> 
14/11/2007 16:15
Mail Size: 10046

To
ian.brown at hsbcib.com
cc
kepler-dev at ecoinformatics.org
Subject
Re: [kepler-dev] event queuing on input ports
Entity
Investment Banking Europe - IBEU







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 




************************************************************
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/6244dec3/attachment.html>