This fixes a field ordering mixup in ShockInABoxInitialize and Grid_HydroShockTubesInitialize that was leading to swapped values of velocity/internal energy.
Adds a new test problem at Hydro/Hydro-1D/ShockInABox which uses the ShockInABox problem type to generate a unitful shock (Mach 3, T2=10^7K, Lbox = 1 Mpc, simulation time=1 Gyr).
Adds a problem generator in make_shock.py that creates a custom shock using unit-ful input values.
Adds ShockInABox to the answer testing suite, which includes a test that
Adds shock finding instrumentation to the shock tubes (off by default) and ShockInABox (on in default ShockInABox.enzo test problem).
Allows the shock tubes and ShockInABox to have GridRank > 1.
I'd like eyes on the modification to ShockInABoxInitialize.C as well as make_shock.py. The usage of Mu is a bit funky. I'm not sure if it should just be set to 1.0 in the ShockInABox problem type.
This passes the quicksuite on medium strictness comparing with enzogolddev, other than having no old answers for the new test, meaning once accepted it will require generation of a new gold standard for the ShockInABox test.
Update 1: Addressing @brittonsmith 's comments.
Sam, this looks great to me. I tried out the ShockInABox.enzo as well as a custom one made with make_shocks.py designed to give the same setup and they produced identical results. I tried using make_shocks.py for a couple other configurations and they also looked good. Your modifications to the problem initializers looked fine to me, but it's probably a good idea to have at least one more person look them over.
I have only two minor comments:
In make_shocks.py, you have Gamma hard-coded to 5/3 in TempJump, but it is accepted as a keyword in setup_shockbox. Just for consistency, it might be a good idea to make it a keyword in TempJump as well in the event that someone would want to try changing it. Also, in setup_shock, it's probably ok to have gamma default to 5/3 instead of None.
There is a commented out call to Grid_ShockTubeInitialize. Since that function doesn't seem to exist anymore, maybe it's worth it to just remove the commented out call.
OhCool. there is global a parameter called UsePhysicalUnit which is used in a lot of the hydro_rk/ problem setups that you may be able to use to your advantage in this problem.
Ah, right, I forgot about UsePhysicalUnit. Do you think this should be refactored to use that, or is this ok as is?
Sam -- I just looked this over and think it is good as is. The usage of mu is correct I believe (TemperatureUnit does not include mu, so you do need to set it). Thanks!