As there is no user-generated content on the DSOL site right now, login is no longer necessary. All content is available to all users. If you want a login id, e.g. to contribute with content about the DSOL simulation framework, or about the simulation research at TU Delft, contact Alexander Verbraeck.

Most DSOL users find the use of the Experiment, Replication, Treatment, and ExperimentalFrame in relation to the Model and the Simulator extremely difficult to use and control. The publish/subscribe mechanisms to move to a next replication or event are difficult to understand, but very helpful in case different experiments or replications run on different computers. As most users don't do this, the question was how to simplify the use of the experimental framework.

So, what's the idea? When executing a simulation, you execute a set of Experiments on a model, using a certain simulator. Different experiments will have different parameter settings for the model. Each experiment can have a number of replications. Each replication has different seeds for the random number generators used, but the specified parameters are the same for all replications within an experiment. An experiment has a certain runtime, warm-up time, time units, and the like for execution. These are also all the same for all replications within one experiment.

The central object is therefore the Experiment. This is the object that links to Replications, Model, and Simulator. The Replication object is an object that indicates the current replication that is being carried out. The Simulator knows its Replication, and the Model now knows its simulator (change in ModelInterface). The Replication is now initialized with its Experiment and not anymore with its Treatment. Treatment and Experiment are combined into Experiment. The list of Replications has also been moved to the Experiment where it belongs. This makes the structure more consistent. The set of Experiments to execute was called an ExperimentalFrame, but this term will be reserved for the experimental frame cf. Zeigler et al. (2000) in the DSOL-DEVS formalism. he new same is ExperimentSet, because it is just a set of experiments to carry out. Static helper methods have been added to help to construct an ExperimentSet with one experiment with multiple replications quickly. This means that an experiment xml-file is no longer necessary -- the experiment can also easily be created with a few lines of code now.

These changes mean that most models that are not extending from DSOLApplication might need a few small changes in the creation and access of the Experiment, Replication, and ExperimentSet. Furthermore, all Models should now implement the getSimulator() method.

The experiment xsd-file has been changed in relation to this, and the replications have been moved to the experiment instead of being part of the treatment. The individual replication elements need to be surrounded by a replications element. This means that experiment xml-files need to be updated as well!

To make it even easier for universities, companies, and government to use the DSOL simulation environment, the license for DSOL has been changed to a BSD-style license. The new license can be found at http://sk-3.tbm.tudelft.nl/dsol/2.0/dsol/dsol-license.html.

Delft colleague Dr. Mamadou Seck has been working over the past months to add a proper version of the DEVS formalism to the DSOL framework. An early version of the code is available through this website. Supported versions are currently classic DEVS with ports, and classic DEVS coupled models. The version is implemented as close to the theory as possible. Until now, speed, ease of use, and integration into the DSOL framework look very promising.

Version 2.1 of DSOL is getting ready. At the end of the week of October 19 2009, the repositories will be updated with the latest version. Documentation of the progress is updated on a daily basis.

DSOL 2.0.13 has the newest version of the open source / LGPL / public libraries on which it is dependent, such as colt, concurrent, jfreechart, jcommon, xerces, jdom, and xml-apis. Furthermore, the core simulation capabilities have been split from the animation and graphing capabilities, to enable a smaller simulation core when no (or other / own) graphics are needed. This means that jstats 2.0.x is split into jstats 2.0.13, which is not dependent on jfreechart and jcommon, but it still is dependent on colt and concurrent, and jstats-charts 2.0.13 which contains the Histogram, XYChart, and BoxAndWhisker plot. jstats-charts is dependent on jfreechart and jcommon. Similarly, dsol 2.0.x has been split into dsol 2.0.13 and dsol-animation 2.0.13. dsol-animation contains the D2 and D3 animation classes, as well as the dsol-specific Histogram, XYChart, and BoxAndWhisker plot. This means that dsol is no longer dependent on jfreechart, jcommon, gisbeans, jdom, xerces, and xml-apis, making the basic simulation package a lot smaller. When animation and charts are needed, just include dsol and dsol-animation through maven, and all graphics packages will be linked automatically. The bugs of 2.0.12 are still there, so stay with version 2.0.9 until version 2.1 is ready.

New and extended download information for DSOL has been posted in the "Download and Use" page in the DSOL menu. There are four basic ways in which you can use DSOL; (1) automatically download using Maven, (2) download a full jar-file with all the DSOL and supporting jars, (3) download individual jars for each DSOL project, and (4) download the sources for DSOL. Each of these methods is further explained in a separate page, you can click on the above links to jump directly to the specific page.

DSOL is a library of Java classes, divided into several projects, that can be used to build object-oriented, multi-formalism, distributed simulation models. At this moment, no high-level 'drag-and-drop' (sometimes called 'grab-and-glue') interfaces have been developed yet, so developing a simulation model with DSOL implicates that you have to program in Java.

There are several ways of developing a simulation model with DSOL.

1. By far the best supported way to develop a simulation model with DSOL is to make your project a Maven-2 project, and create a pom-file that links to the dsol or dsol-gui jar. All resources on which DSOL is dependent will then be downloaded automatically into your Maven repository, and linkages to DSOL classes in your project will work without problems. To get more information on Maven-2 from the Apache website, see http://maven.apache.org. See here for more information on the option of using Maven to create your simulation project.
2. If you are not using an integrated development environment like Eclipse, you don't want to use Maven, or you just want to keep it simple, consider using a JAR-file of the entire DSOL package and implicitly linking to the compiled classes of DSOL. This implies that you have to download a JAR-file of DSOL; For downloading of the dsol-full.jar, see here for more information.
3. If you want a bit more control over how you use the different DSOL projects, you can link to the individual jar-classes of the different DSOL-packages. See here how you can download them. This usually implies setting up your project as a Maven-2 project, although you can also link directly to the individual jar-files in your Java project, without using Maven. See the Development menu for an explanation how to use DSOL with Maven. The Examples menu also contains a number of examples of usage together with Maven-2.
4. The most far-reaching way to use DSOL is to use the source code and explicitly link to the DSOL Java file in the development environment that you use (e.g. Eclipse). This implies that you have to download the full source-code of DSOL; no problem, because DSOL is an open-source project. For downloading the DSOL source code, look under the DSOL 1, DSOL 2 or Resources menu. DSOL has been prepared as a Maven-2 project. To make linkage to the sources easy, it is adviced to make your dsol project also a Maven project, and download Maven-2 from the Apache website, see e.g. http://maven.apache.org. Some information on how to download the sources can also be found here.