You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "r.c.hoekstra" <r....@scarlet.nl> on 2017/11/29 11:56:49 UTC
[scxml] looking for developer for adaptations on Commons SCXML
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.
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.
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.
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
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by "r.c.hoekstra" <r....@scarlet.nl>.
Hi Woonsan,
thanks for the thinking aloud, I really appreciate it.. Response below.
> 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.
Hmmmm interesting. We use a very basic form of scripting, but the rest
we basically don't use. Perhaps with some
redesigning the null data model option would do.
Does it differ a lot, in terms of speed?
>
> 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?
Usually it is a simple set of states, but we use parallel states quite a
lot. Parallel states turned in very handy to model for example
multiple diseases, or a disease and socio-economic "migration" inside a
population.
The events are quite simple, but there can be a bunch of transitions
from each state. Scripts are used, but very basic.
best, Rinke
>
> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by Woonsan Ko <wo...@apache.org>.
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....@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....@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by mike shugar <Mi...@hotmail.com>.
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" <mg...@hotmail.com>
To: "Commons Users List" <us...@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....@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....@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by Martin Gainty <mg...@hotmail.com>.
________________________________
From: r.c.hoekstra <r....@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....@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by "r.c.hoekstra" <r....@scarlet.nl>.
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....@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.
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by Woonsan Ko <wo...@apache.org>.
On Wed, Nov 29, 2017 at 6:56 AM, r.c.hoekstra <r....@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?
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?
>
> 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?
>
> 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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by "r.c.hoekstra" <r....@scarlet.nl>.
Hi Jake,
thanks for your response.
I'll look into SCION too; even if we won't use it it might bring some
inspiration on how to tackle things.
on scaling:
we are currently planning to experiment with running it on a
supercomputer, which also has its disadvantages (planning, etc).
On serialization: that will most likely solve memory problems, but I
doubt that it will be faster. But I must confess I have no experience
with it. The suggestions are interesting enough to do some more
exploration.
thanks,
Rinke
On 30-11-17 15:51, Jacob Beard wrote:
> Hi Rinke,
>
> SCION <https://github.com/jbeard4/SCION> is designed to support
> expensive compilation of an in-memory model, followed by cheap
> instantiation of new instances. However, as you can see in Stefan's
> results, its runtime performance is currently much slower than
> alternatives. It's hard to imagine a faster runtime than generated C
> code, which uscxml appears to support.
>
> As Martin Gainty suggested, to do truly massive simulations supporting
> millions of instances, you may need to scale your workload
> horizontally across multiple servers. I think there are two approaches
> to horizontally distributed state machine simulation. The first is to
> assign each state machine instance to a dedicated machine, where state
> will be kept in memory until it reaches its final state and can be
> garbage collected. The second approach is to serialize each state
> machine state to a database after processing an event; and re-hydrate
> the state machine instance from the state stored in the database on
> processing the next event. This second approach has been used
> successfully to scale simulation across a cluster.
>
> Different SCXML implementations have varying levels of support for
> serializing state machine instances. For example, SCION supports
> serialization
> <https://github.com/jbeard4/SCION-CORE#scgetsnapshot--snapshot>
> directly, and this can also be achieved
> <https://dzone.com/articles/persistent-state-machine> with SCXML Commons.
>
> Hope this helps. Good luck,
>
> Jake
>
>
>
> On 11/30/2017 04:27 AM, r.c.hoekstra wrote:
>> Hi Jake,
>>
>> thanks for your reaction. That is a really useful comparison. And I
>> can see that Apache commons SCXML isn't doing that bad, though the
>> scale is of course logarithmic.
>>
>> Unfortunately the benchmarking didn't test our use case: we need to
>> fire up many instances of the same (relatively simple) scxml model,
>> and if instantiating is relatively expensive, that might change the
>> picture completely.
>>
>> I'll look into uscxml and do some speed testing on that.
>>
>> best, Rinke
>>
>>
>>
>>
>> On 29-11-17 20:22, Jacob Beard wrote:
>>> Hi,
>>>
>>> I thought you might be interested in Stefan Radomski's work on
>>> profiling different SCXML implementations:
>>>
>>> http://lists.w3.org/Archives/Public/www-voice/2017JulSep/0000.html
>>>
>>> https://github.com/tklab-tud/uscxml/blob/master/docs/BENCHMARKS.md
>>>
>>> This indicates that the uscxml implementation is pretty fast. It is
>>> written in C++, so you would need to write additional code around it
>>> to get it to work within the context of your Java programming
>>> environment, but this might be faster than trying to improve the
>>> performance of Apache Commons SCXML by an order of magnitude.
>>>
>>> I hope this helps. Thanks,
>>>
>>> Jake
>>>
>>>
>>> On 11/29/2017 06:56 AM, r.c.hoekstra 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] looking for developer for adaptations on Commons SCXML
Posted by "r.c.hoekstra" <r....@scarlet.nl>.
Hi Jake,
thanks for your reaction. That is a really useful comparison. And I can
see that Apache commons SCXML isn't doing that bad, though the scale is
of course logarithmic.
Unfortunately the benchmarking didn't test our use case: we need to
fire up many instances of the same (relatively simple) scxml model, and
if instantiating is relatively expensive, that might change the picture
completely.
I'll look into uscxml and do some speed testing on that.
best, Rinke
On 29-11-17 20:22, Jacob Beard wrote:
> Hi,
>
> I thought you might be interested in Stefan Radomski's work on
> profiling different SCXML implementations:
>
> http://lists.w3.org/Archives/Public/www-voice/2017JulSep/0000.html
>
> https://github.com/tklab-tud/uscxml/blob/master/docs/BENCHMARKS.md
>
> This indicates that the uscxml implementation is pretty fast. It is
> written in C++, so you would need to write additional code around it
> to get it to work within the context of your Java programming
> environment, but this might be faster than trying to improve the
> performance of Apache Commons SCXML by an order of magnitude.
>
> I hope this helps. Thanks,
>
> Jake
>
>
> On 11/29/2017 06:56 AM, r.c.hoekstra 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.
>>
>> 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.
>>
>> 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.
>>
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org