Monte Carlo moves: adjustable maximum displacement

[g-bauer]

It would be a good idea to implement a demanded acceptance for MC moves that have a displacement (translation, volume or box change). That way, the maximum displacement for the move can be adjusted during the simulation to achieve that acceptance. With a fixed displacement as is, simulations can be very inefficient.

[Luthaf]

Yes, I agree. This can be the default, but should be easy to deactivate, as modifying the MC parameters will change the thermodynamic ensemble.

I have seen this implemented using something like an adjust(&mut self, direction: Direction) method, which could be added to the Move trait. The Monte-Carlo propagator then takes care of counting the current acceptance rate, and calling this method with either More or Less for the wanted adjustment in acceptance rate.

[g-bauer]

I am currently working on this. Having displacement adjustments accelerates equilibration by a lot so in order to verify other implementations (like NPT, tail corrections, comparison to NIST data) I think it is nice to have this first.

I will create a PR soon. For the moment, I added a new struct Displacement which will store:

• number of times a move was called
• number of times a move was accepted
• target acceptance of a move
• update frequency (0 = no updates = fixed displacement, 100 = after 100 calls to move, update delta)
• the current delta (maximum displacement)
• the current range from which to sample
• a method to update the current delta + range according to the current acceptance

The structure replaces delta and delta_range inside a move. Also the McMove will have a new function update_displacement (or smth. like that). Moves that do not need a displacement (insertion, deletion) just do nothing when calling the update function.

I just wondering how much should be done via functions or by direct manipulation of the struct's components (e.g. how to increase the counter for a move, accepted move etc.).

Does that sound reasonable?

Edit: @Luthaf can you add a 0.1 milestone tag to this issue?

[Luthaf]

This seems to be a nice implementation. Another way to do it would be to store an Update (this is a very bad name) struct alongside with the Move:

struct Update {
    called: usize,
    accepted: usize,
    frequency: usize
}

struct MonteCarlo {
    moves: Vec<(Box<Move>, Update)>
}

So that it is the responsibility of MonteCarlo to keep track of the number of time a move was called. This make implementation of new moves easier (we do not need to remember to update the move counts), but leave the delta/delta_range inside the moves.

I just wondering how much should be done via functions or by direct manipulation of the struct's components (e.g. how to increase the counter for a move, accepted move etc.).

I do not have opinion here. Having functions is better if we need to change the internal implementation, but this seems unlikely. So defining a private struct with public members would do it.

Edit: @Luthaf can you add a 0.1 milestone tag to this issue?

Done! You can do it too, using the menu on the left.

[g-bauer]

That is also an option. Since it is handy to track acceptances of every move (even those that do not use displacements) it is better to separate the moves' stats and the displacement updates. I will think about a solution.

[Luthaf]

Leaving this open for tracking the implementation of this feature in the input files.