[kepler-dev] FSMDirector and wire issues

[ian.brown@hsbcib.com]

Hi all,
      I'm still working on my trading system and it's looking pretty good.
I'm using Ptolemy at the moment because it is easier to compile and
understand but  will soon be moving to Kepler to take advantage of the
web-services actor. I have found a few issues so far - they are probably
better suited to the Ptolemy list but when I try to subscribe to that my
mail bounces with DNS resolution errors (it could be my proxy or firewall
... as I sit on a trading floor, the environment is obviously pretty
restricted in terms of external access). I also registered for the forum
but never received the confirmation mail (again could have been filtered by
our paranoid mail server).

The issues are as follows:

1) The wire actor in the DEDomain would appear to be broken. It has a
parameter for an initial value but this is never used - it is stored but it
is not used when initialising the output array. This results in a null
pointer exception when you try to use it with true asynchronous events on
the input. It would only work if the initial inputs arrived at the same
time.

2) The FSMDirector changes the workspace version on a transition. I have a
DEDirector with a FSM modal model in it. In this model is another
DEDirector. Events come in at about every 50 milliseconds and for each
event we have on average 2 state transitions. Due to the workspace
increment (see line 579 in FSMDirector.java) when DEDirector.fireAt() is
next called (which is called by FSMDirector.postfire()) the entire DAG is
rebuilt by DEDirector.getDepthOfActor().
This obviously decimates the performance (there is more than an order of
magnitude difference than when the state transition is not taken) and I
don't think it should be necessary. Can someone who knows the code please
comment - I am happy to investigate the change but would like to understand
the background reasoning for the current implementation first.

As a general comment, what we're doing here is slightly different than what
Kepler / Ptolemy was designed for. Rather then just simulation, we using it
to run a real live system in addition to running it in simulation mode with
historical data. I'm happy to report that so far it looks like it can do
this and is more capable than equivalent commercial systems I have looked.
Well done to all of the developers!

As a last point, can I request a read access account for the Kepler source
code please.

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.