Hi Martin, It sounds like you want a discrete event simulation with script implemented as a large population of state machines.
Are you able to post more details about your simulation requirements? You may be able to achieve them with a different simulation approach or tool. For example, - do individuals have a location and movement that affects disease transmission? - how many diseases will be simulated at time? - do diseases combine to produce different behavior in individuals? - is numeric simulation (eg system dynamics) ruled out? Mike ----- Original Message ----- From: "Martin Gainty" <mgai...@hotmail.com> To: "Commons Users List" <user@commons.apache.org> Sent: Thursday, November 30, 2017 7:26 AM Subject: Re: [scxml] looking for developer for adaptations on Commons SCXML ________________________________ From: r.c.hoekstra <r.c.hoeks...@scarlet.nl> Sent: Thursday, November 30, 2017 4:50 AM To: Commons Users List Subject: Re: [scxml] looking for developer for adaptations on Commons SCXML On 30-11-17 01:49, Woonsan Ko wrote: Hi Woonsan, I'll go through your comments in the text below. > On Wed, Nov 29, 2017 at 6:56 AM, r.c.hoekstra <r.c.hoeks...@scarlet.nl> > wrote: >> Hi List, >> >> We are working at the ErasmusMC hospital at Rotterdam, Netherlands, on >> scientific simulations on the spread of infectious diseases through human >> populations. >> In this project we use Apache Commons SCXML to model diseases. > Just out of curiosity, would you mind sharing the reasons, in higher > level, why SCXML library was chosen for the simulation in the first > place? There are many tools and libs, specialized in simulation, such > as MASON. Was it mainly because of the declarative way of SCXML or > scriptability (e.g, in JEXL) or both? Is there any other background > reason? Yes. The declarativeness was really important. We needed a way to declare the disease processes from state to state, with transitions. And as we were already using other xml files to define other input (population, etc), it fitted the rest of the input perfectly. Besides that, we also use the scripting. We use JEXL for that. > Is it also a considerable option for you to use one of those > simulation-specialized tools or libs instead of SCXML if it can meets > the requirements? Yes we looked into a few of those; I know there are many of them. For various reasons it mostly prooved better to develop our own libraries. But I must confess that I didn't look in those libraries for scxml-like features. I supposed that it would not support that. > >> However, the problem with the present implementation is that it is too >> slow >> for us. We would need a version that is optimized for being instantiated >> 1000000 times in a running simulation. > It sounds really really slow, and the expectation is like 10+ days vs > 1 sec. And is it concerned more on *loading* time before *execution*, > or both? Well, a million might be a bit exagerated for now, but eventually that is what we'd like. A run with about 50.000 takes 2 hours or so to run, if I remember it well. We'd like to scale that up to at least a few hundreds of thousands, without having to wait for hours or without the JVM crashing on out of memory exceptions. And indeed, both loading and execution do matter. A state machine is attached to a person, and persons may be born during a simulation, so that involves instantiating/loading a new state machine. But then, the runtime of a simulation is no extremely long in comparison to the life expectancy of persons (about 200 years or so). > >> For the coming 2 or 3 months we have money available to pay someone who >> could create an adapted, descaled version of apache commons scxml. The >> goal >> is to make it much faster, either by optimizing, rewriting, and dispose >> of >> elements not needed for us. > To be honest, in my gut feeling, it seems infeasible to improve or > rewrite the SCXML library in the shorter term to meet the expectation. > To me, SCXML in both spec and implementation, doesn't seem to be > designed for that kind of highly capable simulation use cases. It's > just too heavy and too much feature driven, IMHO, for that kind of use > cases. Please correct me if I'm wrong. No, I think you're right. It isn't designed to be instantiated many times. Maybe my wording was not chosen well enough. We're not exactly interested in rewriting the SCXML library. There are quite some features of it we don't use at all, for example the data model. We would want a stripped down "version" which is designed for efficiently firing many copies, which uses the declarative features, but which has dropped features which we didn't use anyway. If that still would meet the official set of features that defines scxml isn't really a concern. MG>*if* SCXML/JEXL is pegging 1+ JVM which may cause OOM or Stackoverflow errors MG>as long as your SCXML/JEXL work-units are wholly-contained and atomic maybe zookeeper MG>can be implemented to execute and coordinate these long-running simulations? MG>https://zookeeper.apache.org/doc/trunk/zookeeperOver.html#ch_DesignOverview ZooKeeper Architecture - Apache ZooKeeper - Home<https://zookeeper.apache.org/doc/trunk/zookeeperOver.html#ch_DesignOverview> zookeeper.apache.org ZooKeeper is a distributed, open-source coordination service for distributed applications. It exposes a simple set of primitives that distributed applications can ... > Also, I'm personally doubtful to try to improve SCXML project to cover > the simulation use cases even in the future. It is a reference > implementation and so it has to keep all the features in the spec, and > so on. Long-time less-activeness in this community is another thing. > > Regards, > > Woonsan > >> Our preference would be to find someone who has developed for the commons >> scxml project, or who is at least an experienced user. >> >> In case of anyone interested please reply via this list and we can get >> into >> contact about the details. >> >> best regards, >> >> Rinke Hoekstra > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
