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 <[email protected]> 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.
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
