MFlowCode
New example cases: Lid-driven cavity (compressible), double Mach, and more
Simulate and add several new examples/test cases to the examples/ directory:
I will accept PRs that add these individually (they do not have to be added all at once). Please add small (in terms of MB) visualization images of the results to the example/ directory.
I will also accept additions to this list, particularly problems in 3D or multiphase 2D problems.
Update: More problems!
Can find refs in doi:10.1016/j.cpc.2024.109236
- [ ] 1D: Entropy wave advection problem
- [x] 1D: Shu--Osher, repeat some others from Florian preprint. Sod and Lax shock tubes.
- [x] 2D: 2D Riemann problem' sec 2.5.1 of paper above
- [ ] 2D: Mixing layer
- [x] 3D: Inviscid and viscous isotropic Taylor--Green vortex
- [ ] 3D: HIT: Forced and decaying
- [ ] 3D: Shear turbulence
Original:
-
[x] Shu-Osher problem (1D):
- https://arxiv.org/pdf/2110.05461.pdf
-
[x] Lax shock tube problem (1D):
- https://arxiv.org/pdf/2106.01738.pdf (eqn 59)
-
[x] Titarev-Toro problem (1D):
- https://arxiv.org/pdf/2110.05461.pdf
-
[x] Riemann test problem (2D):
- https://epubs.siam.org/doi/10.1137/0914082
- https://arxiv.org/pdf/2110.05461.pdf
-
[x] Rayleigh-Taylor instability (2D):
- https://arxiv.org/pdf/2110.05461.pdf (example 4.7)
- https://www.sciencedirect.com/science/article/abs/pii/S0021999101968925?via%3Dihub
- https://arxiv.org/pdf/2106.01738.pdf (example 4.7)
-
[x] Lid-driven compressible cavity (2D), finite Reynolds number:
- https://doi.org/10.1016/j.cpc.2022.108527
- https://arxiv.org/pdf/2106.01738.pdf (example 4.12)
-
[ ] Double-Mach reflection (2D):
- https://doi.org/10.1016/j.camwa.2022.12.003
- https://arxiv.org/pdf/2110.05461.pdf (example 4.8)
- https://arxiv.org/pdf/2106.01738.pdf (example 4.9)
-
[x] Kelvin-Helmholtz instability (2D):
- https://arxiv.org/pdf/2106.01738.pdf (example 4.8)
-
[x] Viscous shock tube (2D):
- https://arxiv.org/pdf/2110.05461.pdf (example 4.9)
- https://doi.org/10.1016/j.compfluid.2008.06.008
- https://arxiv.org/pdf/2204.00393.pdf
-
[ ] Double periodic shear layer (2D):
- https://arxiv.org/pdf/2206.14891.pdf (sec 4.2)
-
[ ] 2D single-material triple point problem here
- arxiv.org/abs/2312.17042
-
[ ] Shock-cylinder interaction (2D):
- https://arxiv.org/pdf/2106.01738.pdf (example 4.17)
-
[x] Viscous Richtmeyer-Meshkov instability (2D):
- https://arxiv.org/pdf/2106.01738.pdf (example 4.18)
-
[ ] Underwater explosion (2D):
- https://doi.org/10.1016/j.compfluid.2015.07.010 (fig 12 and 15, sec 4.4)
-
[ ] Compressible decaying isotropic turbulence (2D and 3D!):
- https://doi.org/10.1016/j.cpc.2022.108527
-
[ ] Spherical underwater explosion in a rigid cylindrical container (3D)
- https://doi.org/10.1016/j.compfluid.2015.07.010 (sec 4.5)
-
[ ] Liquid jet in crossflow (3D)
- https://doi.org/10.1016/j.jcp.2014.09.005 (fig 36)
- https://doi.org/10.1016/j.ijmultiphaseflow.2022.104303
- https://doi.org/10.1016/j.ast.2019.05.017
-
[ ] Jet-spray [SprayAB] (3D)
- https://doi.org/10.1016/j.compfluid.2024.106186
- https://ecn.sandia.gov/diesel-spray-combustion/target-condition/spray-ab/
@sbryngelson How do you want to handle the cases that will require hardcoding analytic initial conditions?
@wilfonba for cases with analytic functions, I think we should add some functionality to make this possible without commenting/uncommenting source code. I'm open to suggestions. Some example possibilities are
- Allowing analytic functions in the Python dictionary
- Adding new functions as new patch types
- etc.
What do you think of having the user supply an additional input file with fypp functions that can be included in m_patches.f90?
I'm not sure I understand, I would have to see a small example I think.
@wilfonba What if, in the case.py file you could have something like
'patch_icpp(1)%geometry': 15,
'patch_icpp(1)%pres': '5*x',
'patch_icpp(1)%vel(1)': = '10*sin(2*x**2)',
...
and then in m_patches.fpp or perhaps in m_assign_variables.fpp you would have something that copies/pastes these strings ('5*x' and '10*sin(2*x**2)') into a function that assigns the analytic values depending on the value of x_cc or x_cb or y_ or z_. Something analogous would be done for 2D/3D so you could also have
'patch_icpp(1)%geometry': 7,
'patch_icpp(1)%pres': '5*x*y',
'patch_icpp(1)%vel(1)': '10*y*sin(2*x**2)',
'patch_icpp(1)%vel(2)': '10*x*sin(2*y**2)',
...
for example, in 2D (note that 15 and 7 are the patch numbers associated with 1D and 2D analytical right now). All such analytic string expressions would have to be in Fortran syntax.
I think something like this would actually work really nicely and cleanly, and actually shouldn't require any toolchain changes (or only very small ones). It would require using fypp in pre_process, and a new macro to parse those analytic expressions into the Fortran code. @henryleberre can easily help with those parts easily.
This would actually be quite the improvement to the code, since we could remove all hard-coded analytic functions and basically never need to do that again!
That was the first idea that had come to mind for me as well, but I didn't think to parse the strings in Python rather than in Fortran and some googling suggested doing so in Fortran is rather difficult. I'm sure there's a python package somewhere that takes care of that already though, so I'll do it that way. It is the cleanest.
So I think we don't want to parse the strings in Python at all (I may well stand corrected later).
Instead, we want to use fypp to copy-paste the Python strings into the Fortran code as raw code and do a fypp-powered substitution (like x -> x_cb(i), y -> y_cb(j)) so that you can loop through x/y/z space appropriately.
Ah, I see what you mean now. That makes sense.
I would like this printed and framed 😄
@sbryngelson the 2D single-material triple point problem here (https://arxiv.org/abs/2312.17042) might be worth adding to this.