Backends

[leonardogalliano]

This PR address #14 (comment). Note that this is a major change which breaks compatibility with previous versions.

The key motivation behind this update comes from Daniele’s suggestion: Simulation shouldn't be tied to a specific algorithm. In the future, we should be able to extend the code to Molecular Dynamics, Event Chain Monte Carlo or other algorithms.

Key changes

To tackle this, I adapted the code by decoupling Simulation from its algorithms. Basically Simulation now takes a list of algorithms (that can be used for updating the state of chains or for storing data), each with its own scheduler (i.e. the time steps at which it should be called). This design is inspired by the "Strategy" pattern, making the code very flexible and modular.

Compatibility issues

The old scripts in ParticlesMC will no longer work with this version. The simulation object must now be created with

algorithms = (
            Metropolis(chains, pools; seed=seed, parallel=false),
            StoreCallbacks((callback_energy, callback_acceptance), path),
            StoreTrajectories(chains, path),
            StoreLastFrames(chains, path),
            PrintTimeSteps(),
        )
schedulers = [build_schedule(steps, 0, 1), sampletimes, sampletimes, [0, steps], build_schedule(steps, burn, steps ÷ 10)]
simulation = Simulation(chains, algorithms, steps; schedulers=schedulers, path=path, verbose=true)

and run with

run!(simulation)

Another important point is that the concept of "burn-in steps" has changed: hese steps are now included in the total number of simulation steps rather than being additional steps. Note that the utility function scheduler has been renamed to build_schedule and has been updated accordingly.

[codecov]

Codecov Report

Attention: Patch coverage is 57.66129% with 105 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pgmc/pgmc.jl	0.00%	75 Missing ⚠️
src/metropolis.jl	56.14%	25 Missing ⚠️
src/utils.jl	94.31%	5 Missing ⚠️

Files with missing lines	Coverage Δ
src/simulation.jl	97.05% <100.00%> (-1.33%)	⬇️
src/utils.jl	95.41% <94.31%> (+6.52%)	⬆️
src/metropolis.jl	64.77% <56.14%> (-15.88%)	⬇️
src/pgmc/pgmc.jl	0.00% <0.00%> (ø)

[romainljsimon]

Do we want to call the MC algorithm Metropolis or MonteCarlo @leonardogalliano ?

[leonardogalliano]

With MonteCarlo it complains because it's also the name of the package. And maybe Metropolis or MetropolisHastings is more correct, no? In the end event chain would also be a MC algorithm.

[romainljsimon]

Following your logic, for an ECMC simulations, shouldn't we call a EventChainMonteCarlo function ? So this Metropolis function can maybe be also named MarkovChainMonteCarlo or do you think again it is too broad of a name ?

[romainljsimon]

This is great @leonardogalliano, thanks a lot. Thanks for the advice @dcoslo.

[romainljsimon]

Berfore merging I'll try to rewrite the tests in ParticlesMC and the examples so they work with the new version of MonteCarlo, and give the good results

[leonardogalliano]

Ok thanks 🙏🏻

[romainljsimon]

closes #18
closes #14