[kepler-dev] FSMDirector and wire issues

Edward A. Lee eal at eecs.berkeley.edu
Tue Sep 4 09:24:34 PDT 2007


Ian,

Thanks for reporting these issues.
One resolution and one question.

At 01:03 AM 8/31/2007, ian.brown at hsbcib.com wrote:
>...
>
>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.

This actor was never finished, and shouldn't have been in
the library.  I finished it, and added a test,
so it now works, but then realized
that its behavior is essentially the same as Sampler...
I don't see a real use for it.  Am I wrong about this?



>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.

Yes, this is completely bogus... There is a FIXME there,
which unfortunately will be a fair amount of work to fix...
I'll take this on, however, since being able to use FSM in DE
is very important (particularly for our own PTIDES work).

Edward



>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.
>_______________________________________________
>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://ptolemy.eecs.berkeley.edu/~eal  



More information about the Kepler-dev mailing list