On 27 Sep 2013 at 0:27, Klaim - Joël Lamotte wrote:

...

Can you tell us more about what you mean by Simulation library ? It's a broad concept.

My expectation is that: 1. you have some data representing the state of the simulation; 2. you have a set of rules that have to be applied on each cycle of the simulation; (each cycle might correspond to a time frame but it's important that it's "fixed"); 3. you have some set of events that needs to be triggered (maybe by the rules?); 4. the library take all that in, then provide a function to iterate to the next cycle; 5. each cycle is double buffered (or something similar) that is: a. the library first keep a read-only copy of the state of the last cycle and the state of the next cycle; b. the rules are applied using the read-only last cycle state to modify the state of the next cycle; c. meanwhile, events are collected; d. once the cycle is complete, the events are dispatched or provided as a set to the user code; e. the events will also be used by the rules on the next cycle, which makes it a simulation;

If it's not what the library is about, then I'll need some clarifications. :)

If it is this, then this is a very common design pattern in my testing code. I would have a suspicion that such a library wouldn't offer enough advantages that would cause me to replace my bespoke testing code with it, but if it is (a) highly multithreadable (b) highly scalable (iii) highly configurable, I might just be persuaded. I'd certainly like to learn more. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

Hi All, Following our first request for interest message about a Simulation Library and the (positive) feedback we received, you will will find hereafter: * More details about the simulation formalism * Some hints about implementation details * A few links to relevant pages * Replies to your questions So, about the formalism: We plan to implement DEVS ( Discrete Events Simulation) formalism. Why: - The theory behind DEVS dates back from the 70s, and many simulators used in science today use this formalism. [1] - There has been over 30 years of studies for distributed algorithms for implementing DEVS simulators. [2] - The formalism is general purpose and it has been used in several fields including aeronautics, networking, forest fire spreading, cellular studies. - The simulator implementation is independent from the model to simulate. [1] - The models can compose in other models, it has a hierarchical composition feature. - Transformations have been proposed from almost any other Simulation paradigm to DEVS, but not the other way around, so other formalisms can be use as sub-models in a DEVS simulation using DEVS as an integrator.[3] How we make it general enough: Even though the DEVS formalism is general about models and use cases, there are several ways of implementing a good Simulator running those models. Using different algorithms for the simulator can change performance, scalability and precision in the results. A classification of the Simulation algorithms has been proposed in 2003 [4]. We propose to implement the different algorithms as “simulation engines” to be selected at coding time. An oversimplified example of use: int main(){ devs pdev; // the parallel devs engine devsmodel mod; //some model already implemented simulation sim(mod, pdev); //a simulation gather together a simulator engine and a model sim.runUntil(10000s); //run the first 10000 seconds of simulation. } A few implementation details: - We want to support any type of messages between models (eg. some simulators have constraints to use only ints or strings for messages). - Composition of models should be allowed to be dynamic, so we can reuse already compiled sub-models in different ways with no re-compile time. Suppose the use in a network simulator, changing the network topology should not need a rebuild of the whole simulation. - Logging for models debug, run and results. We think boost::log2 may be a good option for this. - It would be nice to provide the implementation of the adaptors needed to run other paradigm simulations into DEVS (to compose multi-paradigm simulators), we already got some of them working in our previous simulator CD++ [5]. [1] http://mercury.ethz.ch/serviceengine/Files/ISN/861/ichaptersection_singledoc... [2] http://www.cs.utexas.edu/users/misra/scannedPdf.dir/DistributedSimulationNet... [3] http://www.cs.mcgill.ca/~hv/publications/00.CACSD.multiform.pdf [4] http://web.cs.uni-bonn.de/IV/Mitarbeiter/goepffar/scsc_rp.pdf [5] http://www.sce.carleton.ca/faculty/wainer/papers/ACRI-CD%2B%2B.pdf Replies to specific questions: [Q] Marco Guazzone: … So I will be very happy to share the code with you and possibly to join the efforts…. [A] Thanks for jumping in. Your simulator has been released under GPL3 so we can not use the code into Boost (similar to our previous simulator CD++). That is why we are starting from the scratch in ours. Anyway, I will check out the code base for ideas and you are welcome to participate. [Q]Klaim - Joël Lamotte: …. In my experience, most of these simulation implementations have to be written in a very specific way…. [A] If you can separate the Models from the Simulator in your work (which is good in case you want to prove things in paper), then having the possibility to swap the simulator can provide you with measurable improves under low effort. Suppose you got your model running in a simulator optimized for one multicore pc and then you get access to a big cloud to solve a problem. You may be able, changing just a few lines of code, to make your simulation optimized for cloud. Also, I plan to parametrize the engines so they are more adaptable, as the engine proposed by Peschlow-Martini which is used in Moose simulator[6]. [Q] Niall Douglas: … if it is (a) highly multithreadable (b) highly scalable (iii) highly configurable, I might just be persuaded…. [A] We hope to cover those 3. [6] http://nsl10.csie.nctu.edu.tw/products/nctuns/NCTUnsReferences/a14-peschlow.... -- Damian Vicino, PhD Candidate Université Nice Sophia Antipolis & Carleton University Dr. Olivier Dalle, Maître de Conférences, Université Nice Sophia Antipolis Pr. Gabriel Wainer, Carleton University ----- Original Message -----

From: "Damian Vicino" To: boost@lists.boost.org Sent: Friday, September 27, 2013 1:37:32 PM Subject: Re: [boost] Is there interest in a Simulation library?

Hi, Thanks you everyone for the quick replies. The replies come up a lot faster than what I expected. I will try to write a document for next week explaining what we are planning to do for the library. I hope the document will reply all your questions and work as an starting point for the discussion of the architecture and implementation details. BTW, if someone going to the Open World Forum next week, we can meet and have some discussion in person too. Best regards, Damian

-- Damián Vicino, PhD student UNS/Carleton Centre National de la Recherche Scientifique

----- Original Message -----

...

From: "sguazt" To: boost@lists.boost.org Sent: Friday, September 27, 2013 9:59:42 AM Subject: Re: [boost] Is there interest in a Simulation library?

On Thu, Sep 26, 2013 at 6:40 PM, Damian Vicino wrote:

...

Dear All,

Following the on-going efforts on development and standardization of C++, especially application-oriented libraries, we are soliciting expression of interest within the C++ community for a new Boost library for building Discrete-Event simulators.

We plan to build this new library on the latest features of the C++11 standard, for possible inclusion in a future version of the C++ standard.

This work is based on our experience in building C++-based simulators for over 20 years, exploring various optimization and algorithms, and leading to a significant number of reseach publications. Writing a new version of a simulation library based on the latest features of the C++ language has started as new joint research project of University of Nice Sophia Antipolis, UMR CNRS 7172 (FR), INRIA Sophia Antipolis (FR), and Carleton University (CAN). Of course, anyone interested in joined this effort is more than welcome!

Hello,

I'm very interested.

I and my research group used discrete-event simulation (DES) for years for our research.

We also developed a generic C++ DES library. You can find it at:

https://github.com/sguazt/dcsxx-des

It provides different output analysis (currently, independent replications and batch means methods) and different output statistics (mean, quantiles, ...). One of the goal of the library, in addition to be generic, is to allow flexibility in event registration for user applications. To do so we provide a minimal set of events (e.g., begin/end simulation, ...) and other event can be easily added to the engine by mean of event subscription. We use Boost.Signals2 to handle event triggers and subscriptions. The event queue can have different implementations (e.g., priority queue or a simple list), which is useful in case you have particular needs of event management (e.g., event rescheduling, event cancellation, ...)

Unfortunately I'm the only maintainer of that library, so progress and improvements are very slow (currently, the development is idle since I'm doing research on real testbeds). The architecture of that library was not perfect and I think there are a lot that can be improved

So I will be very happy to share the code with you and possibly to join the efforts.

Can you provide more details?

Best,

-- Marco Guazzone, Ph.D. Department of Computer Science (University of Torino, Italy) Department of Science and Technological Innovation (University of Piemonte Orientale, Italy) web: http://people.unipmn.it/sguazt

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi, In the context of the (oversimplified) example: Time is virtual and "parallel devs" is an algorithm defined in [1] by Alex Chung Hen Chow and Bernard P. Zeigler in 1994. It defines how to run several submodels in parallel and obtain the same results as running everything sequentially, but faster. [1] http://informs-sim.org/wsc94papers/1994_0104.pdf -- Damián Vicino, PhD student UNS/Carleton Centre National de la Recherche Scientifique ----- Original Message -----

From: "Klaim - Joël Lamotte" To: "Boost Developers List" Sent: Tuesday, October 1, 2013 3:41:37 PM Subject: Re: [boost] Is there interest in a Simulation library?

On Tue, Oct 1, 2013 at 3:32 PM, Damian Vicino wrote:

...

An oversimplified example of use: int main(){ devs pdev; // the parallel devs engine devsmodel mod; //some model already implemented simulation sim(mod, pdev); //a simulation gather together a simulator engine and a model sim.runUntil(10000s); //run the first 10000 seconds of simulation. }

What does parallel_engine means in this context? It parallelize the processing of a cycle?

Also, could you clarify why the interface would use time values instead of cycle count? Or is the time value relative to a virtual clock instead of real time? In my experience, it is incredibly useful to not associate time with the processing of a cycle, so that the user code can work with it in different kind of context.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, Oct 1, 2013 at 3:32 PM, Damian Vicino wrote:

Hi All,

Following our first request for interest message about a Simulation Library and the (positive) feedback we received, you will will find hereafter: * More details about the simulation formalism * Some hints about implementation details * A few links to relevant pages * Replies to your questions

So, about the formalism: We plan to implement DEVS ( Discrete Events Simulation) formalism.

Hi, I heard about the DEVS formalism but never used. When time permits, I'll try to investigate about it and also I'll try to rethink how my past simulation projects could fit with it. Just for info. I found this C++ library DEVS++ http://odevspp.sourceforge.net/ Do you know it? Cheers, -- Marco