Allows GEMC simulations to control which boxes run MP moves

[LSchwiebert]

This patch resolves issue #520 by adding two boolean flags that can be used in the config file. The flags are:

MultipleParticleLiquid
MultipleParticleGas

The default settings are true for the liquid box and false for the gas box. The boxes are labeled at runtime, before running each move, based on the density of each box.

This applies only to GEMC simulations. The idea is that a MP move typically makes sense to be run in the liquid box because of the higher box density, however, any combination of flags is valid, except for setting both to false, since that would prevent the MP move from working.

This patch works for both force-based MP and Brownian-motion MP moves. It does not change the behavior of the NeMT move, which picks the box via a different process.

[bc118]

When finalized, Can someone make a few examples and I can add to mosdef - GOMC?

[LSchwiebert]

I've attached a folder that you can use for an example. You can see the new flags there and you can modify them to get different examples. Note that the patch changes the behavior of only GEMC simulations.

It may be that 1M moves is too many, so you can edit that accordingly.

GEMC Box-Restricted MP Moves.zip

[bc118]

So this basically turns on/off (True/False) for the Multiparticle in (liquid/gas) phases?

A few other comments/questions?

• Do we want to call it? MultiParticleGas or MultiParticleVapor?

[bc118]

When this PR is merged, the MoSDeF-GOMC PR to add it is here (GOMC-WSU/MoSDeF-GOMC#83), which can be approved then and merged also then.

[LSchwiebert]

I'm fine with changing the name. I'll leave it up to @jpotoff to make the decision. OK. Once the PR is merged, I'll proceed with the other one.

I'll also update the manual with the next release.

[LSchwiebert]

The code works by calculating the density of each box and labeling the box with the higher density as the liquid phase and the box with lower density as the gas phase. This is done before each MP move, so adjusts if the liquid and vapor phases swap boxes.

If both boxes had the identical density, then it would pick box 0, but if there was even a minute difference between the two boxes, then it would pick that one and that could be arbitrary.

[bc118]

Cool! Thanks for the input. If the name changes, let me know, as it is a quick find and replace fix.

Confirm also that this is only needed when multiparticleFreq>0 and no other condition

[LSchwiebert]

Either MultiParticleFreq > 0 or MultiParticleBrownianFreq > 0

These variables are ignored for all other moves.

Also, it isn't used if you enable NeMT moves.

[bc118]

• MultiParticleBrownianFreq is not included in MoSDeF-GOMC, but I see it in the manual. Is there any other options here? If not, it it added to the MoSDeF-GOMC PR now.

• Is NEMTMCFreq done, as it is not in the manual? If so, are there examples? How many options are with it...? What are the allowed combinations and ensembles? What are the default settings.?

• This is what I have from my past notes for NEMTMC:
  NEMTMCFreq 0.20
  RelaxingSteps 25
  MultiParticleRelaxing true
  MultiParticleBrownianRelaxing false
  SampleConfFreq 0.15
  LambdaVDWLimit 0.1
  ScaleAlpha 0.5
  MinSigma 3.0
  ScaleCoulomb false

[LSchwiebert]

The Brownian Motion MultiParticle move and the NeMT moves were both written by Mohammad. To the best of my knowledge, they are both done. I don't know the answer to your other questions. I'm not sure if he prepared any examples or documentation.

It would be better to open new issues for this. Either in the manual or examples, wherever you need them. It's outside the scope of this PR.

[bc118]

Ok.

[jpotoff]

Are we calculating the density of each box in Multiparticle.h before each MP move? Since we output the density to the log file, aren't we already calculating the density of each box somewhere else in the code?

[LSchwiebert]

Yes. I couldn't find anywhere that we were saving the density, so I recalculated it. I agree that's not ideal, so we can try to find a better solution.

[jpotoff]

Considering the computational cost of doing the density calculation vs. the Multiparticle move, what you have seems like the most reasonable solution for now.