Hi Rinke, Thanks a lot for the info! Please see my comments inline.
On Thu, Nov 30, 2017 at 4:50 AM, r.c.hoekstra <r.c.hoeks...@scarlet.nl> wrote: > 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). So, I assume you have your own simulation runtime engine implementation which instantiates and executes environments and agents. And each agent instance in your project is a SCXML state machine, right? I'm not an expert on this simulation thing and tools, but just thinking aloud that it should also be possible to use an external simulation tool's runtime engine (instead of your custom runtime engine) and implement agents, embedding SCXML stuffs, based on their API. I'm just wondering if it is a feasible idea and if there's a very extensible tool meeting your needs. In other words, it could be about creating a new bridging library to support smaller set of SCXML for specific simulation tools (not improving/rewriting/forking hugely in SCXML project). Again, just thinking aloud... > > >> >>> 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. Regarding the data model, have you tried "Null Data Model" [1] option? >From the source, it just skips cloning if it is using that option. org.apache.commons.scxml2.SCInstance#cloneDatamodel(Datamodel, Context, Evaluator, ErrorReporter) for instance. Regarding your usages, is your model a set of simple states with bunch of context values (as state attributes), no parallel states, with simple events, transitions and some scripts, basically? Regards, Woonsan [1] https://www.w3.org/TR/scxml/#minimal-profile > > >> 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
