call of isabsorbing() during the simulation.

Now the package is a bit more efficient than DiffEqJump.jl with the
Catalyst.jl interface which is encouraging, see bench/pkg/catalyst.jl.

The two Cosmos tests checks the statistical correctness of estimated
distance value for R1,R2,R3,R5 experiments. Also, they test that all
trajectories are accepted.

A bunch of errors were fixed in automata files (Cosmos .lha and julia
./automata files) and simulation function that introduced statistical
bias, i.e. approximated values that were closed but not in the
confidence interval. The general structure of simulation and was
reworked in order to suits well te behavior of Cosmos.

copyto! is implemented for LHA states.

Automaton G works almost well, a bias in the distance is identified
compared to Cosmos when one of the model parameters is zero.

Implementation of volatile_simulate, which simulates SynchronizedModel
without saving values: it only returns the last LHA state of the
simulation.

Implementation of distributed computations of variable automata with
volatile_simulate.

Tests passed.

Fix about methods of SynchronizedTrajectory + tests.

Simulation for ParametricModel works.

efficient.

First bricks of the automaton_abc algorithm.

slight improvement in allocation and time in benchmark but too small.

small.

Fix of a misbehaviour of isbounded() for trajectories.

Add several convenient methods for parameters of model.

Next step: implementation of simulate with resize!.

Add of set_time_bound!
Add of a first notebook example to explain the package.

Add of a new type of Trajectory: SynchronizedTrajectory which is created
by the simulation of a synchronized model with an LHA.

Simulate function for SynchronizedModel executes and is tested by two
simple models.

Next step : Cosmos based tests.

Add of several useful functions for access values of model, lha and
trajectory objects.

an object.

Type stability of simulate, dist, read_trajectory seems to be preserved.

First implementation of LHA.
Synchronized simulation not yet tested.
Reading of trajectories with LHA seems to work with one test basted on
simulations that checks that the last value is well read.

Major fix of type unstabilities which improved performances.
For now on, we observe for pygmalion benchmarks:
+2x speed simulation compared to simulation of models.
100x speed in terms of reading values (no allocations).

Add of bench for @view macro.

Fix of a major issue in the simulation: sometimes the number of states
wasn't consistent. Add of test to check the consistency of the
Trajectory structure (unit/check_trajectory_consistency).

Implementation of the lp distance for trajectories.
Add of unit tests for lp distance.

can be set by the user. Changes of SIR and ER.

previously loaded model). The package warns when this happen.

Several benchmarks for the data structure. Now we chose the row buffer
method according to results (mainly because the trajectory access with
far way faster, but strangly not that much differences in other cases).

In fine I give the Abstract and Static arrays types up.

- Real => Float64 for better performance (Real is an abstract type)
- Should not create a type inside the model because the compiler fails
at estimating the type of the output of the f function (detected with
@code_warntype)
- Intentionaly ER is not as well improved as SIR in order to check the
differences of performance.

- Add of benchmark scripts that compares perf wrt pygmalion.
=> As expected it is bad in terms of reading cost (because of row by row
matrix read) but it is also not good in terms of simulation cost.
hcat seems to perform badly, should investigate.

SIR model.

- Evolution of the ContinuousTimeModel type
- simulate, easy access to Trajectory fields
- fix of several errors

run the tests
Function load_module in core + test

Two folders:
- core/ which contains the essential files for the packages
- tests/ which contains tests and benchmarks of other packages / methods

For now on:
- we wrote minimal tests in tests/ (a simulation of SIR model) that should run for
a first minimal version of the package
- we described in core/ the general structure of essential
types, how they articulate each others and the minimum methods we should
implement for a first version that runs the tests.