New example cases

[jjhans]

This issue is intended to identify and add new example cases to the code which demonstrate recently added features (e.g. constant area duct for psuedoshock, recreating test cases from literature, etc.). Cases will be added to the /examples folder and should be as mutually exclusive and collectively exhaustive as possible.

[nlaing613]

@TimothyEDawson
I just went through the existing validation cases we have and since the data uploads to Git are meant to be limited/changed rarely I thought I'd ask:

• I plan on using time (s) and all SI units in the CSVs; is this fine?
• I imagine preference should be given to experimental measurements wherever possible. If an experiment ran a complementary CFD case (with good results) and it adds additional variables for comparison, should we include this? For example, in the MASIV experiments, they only provide pressure measurements, but they did a side-by-side Fluent simulation, allowing for simulated estimates of Mach and temperature.
• In some cases, we can either plot the spatial state at selected times, or probe data over time. For steady cases it makes sense to plot spatial profiles, but do you have any preference for the time-resolved cases? I realize the shock tubes are a unique case since they typically have limited pressure probes.

[TimothyEDawson]

@nlaing613

• Yes, MKS is ideal. Any conversions for plotting purposes, e.g. Pa -> kPa, can be done within the scripts.
• Correct, experimental validation is the most important. Published CFD data is also good as a secondary point of comparison, I'd be good with including it.
• Generally it should be one time instance per row, and each row could include e.g. pressure data from a set of probes. The probe locations could be stored in a header comment or separate file. If you have a case which is well resolved in both space and time, such that storing all the spatial data for a time instance in one row doesn't make sense, we would need to consider using HDF5 instead and whether that dataset should be included within the repo.

Another thought I had was to include source attributions in a header comment in the CSV files. E.g. # Digitized from [full journal paper reference]. And also include a header comment with variable names and units for each column, like # Time [s], Temperature [K], Pressure [Pa], .... What do you think?

[nlaing613]

@TimothyEDawson I definitely agree with including the source attributions, and I also think having some kind of header column is the best; I think we're on the same page here. I'll work on reformatting the experimental data I have for the cases we've discussed.
For the instance of CFD data, I'll just put it in a separate file from the experimental data for now.
A lot of the cases I have are naturally more spatially resolved; these include the constant area duct/UMDCI (as they are time averaged b.c. pseudoshock is unsteady), and the MASIV and HiFiRE are also steady for a given equivalence ratio.

With this in mind, maybe x in one column and the probe data on the remaining columns? I can see the benefit of HDF5 here if it's time/space resolved, but fortunately those are relatively rare. I know the original Emami dataset had both measurements, but a later numerical simulation of this experiment simply pulled three probes along the duct.

[TimothyEDawson]

Hey @jjhans , could you push your updates to the 87 branch? I'd like to make some updates to the stack and include those in it. There will likely be some conflicts with some of the changes I'm making which I'd like to resolve as soon as possible.

Also, if these example updates will take some time to all come together, it would be a good idea to split them out into separate branches so they can be merged as they become ready. You can link them to this issue using the "Create sub-issue" button.

[jjhans]

Hi @TimothyEDawson, sorry for the delay on getting this up. Just pushed an initial set of examples to the 87-new-example-cases branch. Here's where things stand:

Pushed:

• 01_sod_shock_tube compares WENO5/O1 and HLLC/LF scheme combinations against the analytical Sod solution
• 02_isentropic_nozzle validates the geometry/area-change handling against quasi-1D isentropic nozzle theory
• 04_jicf_heat_release_profile JICF heat release profile case
• 06_autoignition_vitiated_flow autoignition in vitiated flow

Notes:

1. Cases 04 and 06 run, but the results aren't good enough yet - they show deficiency in the chemistry so they're currently more useful as development diagnostic tools than as polished examples. Will take looking at FPV vs FRC to resolve this most likely

2. What should we do with the old example cases (from the original StanShock)? Delete them outright, or move them to a legacy_validation/ folder? Haven't moved them yet since it sort of depends on how this full set of examples looks once it gets filled out a bit more

3. HyShot II JIC case: I've been reworking this one but broke something in the process. Didn't push any changes for now.

[TimothyEDawson]

@jjhans Hey James, thanks for the update! We can discuss this more at today's meeting, but some quick thoughts:

1. For the Sod shock tube cases, it would have been a good idea to first git mv my sod_problem.py file and then make your changes instead of making a new copy of it. That way it would retain the history of the file. I may be able to fix it post-hoc.
2. I'd like to do a rebase to bring this branch up to date with the latest changes to develop, let me know if that's okay to do.
3. For the legacy cases, I'd like to merge them into one generalized setup similar to how I did the Sod problems. If I recall correctly, cases 1-3 are very similar, and case 4 is a bit different. I haven't had time to sit and think about how best to handle them, but I definitely want to get rid of the use of imageio in case 4 as it is only used there and also has some known vulnerabilities that Github keeps flagging.
4. Regarding the HyShot II cases, we should probably start with my rework-hyshotii-cases branch to avoid diverging workflows. I could go ahead and merge that in to this branch while in the process of rebasing. Did you want that to be 03?