Gibbs Ensemble scripts

[jhossbach]

This is an updated version of #3903

Several updates were performed:

• Multiprocessing and Communication via the internal Pipes was used instead of subprocessing and communicating via socket
• The sample system no longer uses correction terms but a truncation of 5 sigma instead

This updated way of communication between processes is far more efficient than using TCP connections which is either a result of an increase in latency or the multiprocessing module uses internal methods to efficiently use nonblocking communication between the processes.

The simulation has the following structure:

• The run_sim.py script starts the clients and controls them (same functionality as the socket script in WIP: Gibbs ensemble scripts #3903)
• The gibbs_client_class.py script contains the client class with the methods needed
• The client_system.py script initializes the system in every box

[jonaslandsgesell]

Would you mind investigating using MD moves instead of MC moves to propagate the internal states of each system. Just instead of moving 1 particle and computing exp(-beta Delta E_pot) in an MC step, run x MD steps (e.g. 10-100) and compute exp(-beta Delta E_pot) from before and after running MD.
This would allow to simulate polymer systems and should have much faster decaying autocorrelations of observables.

Running MD will require that you initialize to the velocities with a Maxwellian distribution like e.g. in

espresso/src/core/reaction_methods/ReactionAlgorithm.cpp

Line 503 in ae3094f

vel[0] = std::sqrt(temperature) * m_normal_distribution(m_generator);

after creation or when you insert new particles etc.

You will also have to avoid inserting particles closer than e.g. 0.9 sigma to avoid instabilities in the MD (see

espresso/src/core/reaction_methods/ReactionAlgorithm.cpp

Line 591 in ae3094f

if (d_min < exclusion_radius)

) for fulfilling detailed balance you may then also not remove particles which were closer than this exclusion radius. You can just use the logic from within the reaction ensemble here.

[RudolfWeeber]

I agree that MD moves will likely accelerate things. But let’s keep this Pr to the basics. Once it is in, we can extend upon it.

[jhossbach]

For now I updated some comments, added docstrings and copyright disclaimers. Things that still need to be done:

• Create README.md
• Use subclass instead of free function in client_system to give rise to possible truncation correction
• Actually implement truncation correction for better evaluation with the literature available
• Rewrite the create_fits script to a more pythonic way
• Add uncertainties to the plot
• Add more commenting for lists throughout all scripts
• Change the move counters to be Enum dict entries
• Update the trial move functions to return True/False and no longer use the 'global' keyword
• Update the Client class to save particle information via the ParticleHandle.to_dict() function

[RudolfWeeber]

Thank you. Just two minor issues left

[jngrad]

Here is a review from the point of view of code maintainability. I'm not sure the shell script can be tested, unless we can extract the number of steps as an external variable and call the script from a python subprocess.

[jngrad]

@jhossbach please apply suggested changes with option "Add suggestion to batch", we have limited CI resources :-)

[RudolfWeeber]

I like using handles to store the particle data, but why not use it for the other methods as well? This way one doesn't have to store the data with the to_dict() >method

The handle is a proxy to the actual particle in the Espresso system. Once you delete the particle, the handle is meaningless. Hence, just storing the handle is not enough information to revert a removal of a particle. You have to store the actual particle properties (as a copy), before removing the particle.

[jhossbach]

With fe1f069 I did a last sweep over the plot script. Please review it again.

Thank you. Just two minor issues left

[KaiSzuttor]

looks very good, i just have added a few minor comments

[RudolfWeeber]

From my side, we're good, here.

[jngrad]

I'll have another look and rebase the PR. There are 68 commits, many of which are fixups and reverts.

[jngrad]

A few suggestions. They have been addressed in 684a12d

[jngrad]

The PR was rebased to remove accidentally committed files from the git history and squash the fixups. I've also added copyright headers and wrapped long lines (see git diff 02c06cbc94c..7fe8f511489233).

[jngrad]

ok from my side

[jngrad]

@RudolfWeeber don't forget to change your review from "Requested changes" to "Accepted", then it can be merged

Requested changes were applied.