Add MD LJ validation tests

[joaander]

Description

Add validation tests that check the energy and pressure or density with the NVT, Langevin, and NPT integration methods.

Motivation and context

Ensure that MD simulation compute correct results.

Related to #210 but does not completely solve it.

I also add a volume property to ComputeThermodyanmicQuantities. This is available elsewhere (i.e. the system box) but not as an easily loggable property.

How has this been tested?

I tested it locally on the serial CPU configuration. CI will check it on the GPU and MPI configurations.

Change log

Added:

- ``hoomd.md.compute.ThermodynamicQuantities.volume`` property.

Checklist:

• I have reviewed the Contributor Guidelines.
• I agree with the terms of the HOOMD-blue Contributor Agreement.
• My name is on the list of contributors (sphinx-doc/credits.rst) in the pull request source branch.

[joaander]

This isn't quite working right yet. I'm currently working on some additional checks to see if I can get more reliable results from the test.

[joaander]

This is ready for review. I had to change a number of things from the initial design. I'm no longer using the NIST reference data. That system size was too small for MPI validation and most of the state points are in the two phase region so it is not suitable for NPT validation. The tests did pass with the NIST data in NVT.

Instead, I run the test in HOOMD for a longer time to obtain reference energies and pressures. This is still a good validation test, as it cross validates NVT, NPT, Langevin (and later, MC) methods. If they don't all agree on a state point, something is wrong with one or more of them.

The validation test runs for 65536 time steps sampling - this takes about 10 minutes on the CPU and is just long enough to get a decent measure of the mean quantities. However, 10 minutes is longer than I hoped for, so I also reduced the number of state points to 1 to keep the validation testing time low. We have many more validation tests to add and need to keep the time reasonable.

[b-butler]

I have a few comments and suggestions. Overall the code was fine (I liked your use of custom Actions in ListWriter). I don't know a way to speed this up more so 10 minutes will need to be okay (plus more time later).

[b-butler]

Don't subshells only require a single set of parenthesis or am I missing something?

[joaander]

pytest || cat pytest.out.1 executes cat when pytest fails and then assumes the exit code of cat. Thus GitHub Actions thinks the test passed when it actually failed. Adding the exit 1 raises the error code.

I don't know whether one ( would work here or not - but (( does work as tested on this PR.

[alacour]

I think it looks good. I do have a few suggestions for speeding it up, which may enable more or faster tests. To be complete, I am including some obvious suggestions:

1. Lower density runs. Simulations at lower densities will probably run much faster for every thermostat. A much lower density run (<0.2) would probably see a speed up of > 5 times.

2. Not initializing with an FCC lattices. It may take time to fall apart, while a simple cubic lattice would fall apart faster and may enable shorter simulations.

3. Fewer particles. Maybe more tests could be added where the phase behavior could be tested with 1 CPU.

4. Other Potentials. The WCA potential has a short cutoff of 2**(1/6) and probably runs multiple times faster. Instead of adding other tests for LJ, maybe other test could use WCA or other short-range potentials.

[b-butler]

Feel free to resolve comments that you don't think warrant addressing. I am only requesting changes to remove an errant comment (or what I think to be an errant comment).

[joaander]

Thanks for reviewing @alacour!

I think it looks good. I do have a few suggestions for speeding it up, which may enable more or faster tests. To be complete, I am including some obvious suggestions:

1. Lower density runs. Simulations at lower densities will probably run much faster for every thermostat. A much lower density run (<0.2) would probably see a speed up of > 5 times.

You get a speedup in terms of TPS, but the autocorrelation times of energies, pressures, etc increase because there are fewer collisions to randomize things. In practice, these statpoints needed to be run 5 times longer as well, negating the performance boost.

2. Not initializing with an FCC lattices. It may take time to fall apart, while a simple cubic lattice would fall apart faster and may enable shorter simulations.

I tried this, it doesn't seem to make much of a difference. I implemented the FCC structure as it should help validate systems in the solid phase though I found the fluid gave quicker results for validation.

3. Fewer particles. Maybe more tests could be added where the phase behavior could be tested with 1 CPU.

Unfortunately, the MPI simulations need quite a few particles in order to have a large enough box to communicate. I do reduce the size for the serial runs, but I'm concerned that if I reduce it much further finite size effects might make the validation reference point invalid.

4. Other Potentials. The WCA potential has a short cutoff of 2**(1/6) and probably runs multiple times faster. Instead of adding other tests for LJ, maybe other test could use WCA or other short-range potentials.

This has the most promise. Ultimately, I didn't try it because I ran out of time to apply to this.

[b-butler]

LGTM