Hi Rinke,

I think you can measure a rough range of how many times to invoke SCXMLExecutor 
(#go(), #triggerEvent() for instance) in simulation on N instances. Then you'll 
probably able to get an estimate of the total execution time somehow.
If the estimate of the pure SCXML executions can possibly meet your 
requirements, then I think the next thing to consider might be how to reduce 
IOs if you have to (de)serialize those instances. In one of our projects, we 
initialize a root context and an executor every time before triggering events. 
So, the SCXML definition is responsible for initializing itself (to move the 
right current state) from the given root context (in script blocks). I think 
this pattern could help reduce the amount of (de)serialized data, and so reduce 
IO.

Regards,

Woonsan


On Monday, May 12, 2014 12:58 AM, R.C. Hoekstra <r.c.hoeks...@erasmusmc.nl> 
wrote:
 

>
>
>Hi list, 
>
>As written before, We're a university team of scientists working on multi 
>agent simulations of tropical diseases for a world health organization 
>project. A disease can be considered as a state machine, with the patient 
>going through various states and transitions, each triggering new events.
>
>We've managed to make a working example of a xml file where a patient is going 
>through various stages of the disease, including treatments with medicine. Our 
>most important concern at the moment is: how efficient is it? Our aim is a 
>multi agent simulation with possibly a few 100,000 of instances of a State 
>Machine engine (SCXMLExecutor). I'd like to share the code setup with you 
>guys, and maybe you can give some clues on how efficient it will be in terms 
>of performance/speed, and maybe some hints if an alternative approach would be 
>better?
>
>general setup
>we have a Population object (a wrapped list) containing all agent objects. 
>Each agent is assigned an SCXMLExecutor as the engine, so there are many 
>instances of SCXMLExecutor. We use the default JexlEvaluator, and each 
>SCXMLExecutor gets the agent it belongs to assigned to the rootContext, so the 
>agent's properties can be accessed from the scxml file. 
>
>Transitions
>Our transitions are usually of a special type: a patient usually stays x days 
>in a certain state, after which the transition takes place. The x days is 
>determined on basis of drawing a random number from a statistical 
>distribution. There is usually more than one possible transition; each with 
>different probabilities. 
>So the scxml file must contain the following information: 
>* distribution name and parameters to determine the time until next transition.
>* A number coupled to each possible transition indicating the likelyhood that 
>it happens. 
>
>We solved this in the following way:
>* distribution name, mean and variance parameters, and chances are defined in 
>the datamodel as single variables: <data id=”distr”>
>in each state's onentry we set these variables with the values specific for 
>that state, via the assign tag. The chances variable is defined as an array: 
><assign name="chances" expr="[0.05d, 0.10d, 0.20d]" />
>* The state's onentry also contains a send tag. Send passes the agent's id, 
>the forementioned variables and the event concerned. 
>The send message is captured by our own implementation of EventDispatcher. 
>This does two things: 
>** It draws the random time based on the passed distribution parameters. It 
>schedules this in our own discreet event manager. When the desired time has 
>passed, the discreet event manager passes the correct event back to the 
>correct SCXMLExecutor instance. 
>** It determines which transition will be chosen by drawing a random number on 
>basis of the chances array. This results in an index number of the transition 
>to be chosen. This index number is passed as payload to the event. The scxml 
>file checks this index number in the cond attribute of the transitions.
>
>Agent properties:
>Each disease state also has its effect on the agent's properties, for example 
>the infectivity of the agent, or its fitness. The agent was passed to the 
>rootContext, so the onentry of each state contains code to set the agent's 
>properties specific to that state: 
>                <script>
>                    agent.infectivity = 1
>                </script>
>
>This is our overall approach. I'd be happy to receive any comments; 
>specifically tips regarding the expected speed/performance. 
>
>best regards,
>Rinke
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>For additional commands, e-mail: user-h...@commons.apache.org
>
>
>

Reply via email to