This PR modifies the Kelvin Helmholtz problem type. The old problem (which you can still use when you set KHRamp = 0, sets up a discontinuity between the two fluids and perturbs it with random kicks in the y-velocity fluid throughout the box. For this reason, it may excite any number of modes in the KH instability, but it will not be reproduceable nor will it converge with increased resolution.
The new problem (set KHRamp = 1 by default) produces a ramp connecting the two fluids continuously in density and x-velocity so the transition is smooth. It perturbs the fluids with a sinusoidal perturbation in y-velocity. This yields reproduceable results and converges in behavior with increased resolution.
I have updated the documentation to reflect this change. I have included two additional tests in the test suite: one for a unigrid sim, one for a single-level of AMR, which are included in the quick suite, push suite and full suite of tests (run time is less than a minute for both).
While similar functionality to the "Ramp" version of KH existed in a test problem in the code base under the hydro_rk subdirectory, I had difficult making it work to my desired level, so I redeveloped it here.
UPDATE1: Updated the PR to accommodate the comments made by Brian O'Shea and Sam Skillman. Removed 'Level' parameter from arguments, changed BaryonField calls to match convention, and added mersennes RNG so that KHRamp=0 mode with random perturbations yields consistent results over multiple identical runs (with the same seed).
I made a couple of notes within the source code. I realize that the internals of these routines are mostly holdovers from when Alexei wrote the original versions, but could you take a few minutes to update the programming convention to make it a bit more legible? Otherwise, it looks great and I'm glad you've put the ramp into the non-hydro_rk version of this test problem - I have had a huge problem getting that to work correction!
Hi Cameron Hummels , this looks great to me. I tested in serial and parallel with AMR on/off with ramp on/off for the AMR one, and everything seems good. For example, now without the ramp I get the same result from one run to the next. I'm going to merge since this is a pretty straightforward improvement in all aspects!