Support for structured rectangular grids

[stillyslalom]

Calculations involving shocks often require domains with fairly large aspect ratios - my experimental facility, for example, is approximately 9 meters long, but only 0.25 meters wide. Are there plans to support such domains without needing to use a less-efficient CurvedMesh? The infrastructure of CurvedMesh could presumably be specialized/baked-in for common uniformly-curvilinear coordinate systems (Cartesian/cylindrical/spherical).

[ranocha]

As mentioned in the docs, the CurvedMesh is currently in an experimental stage (and will probably be renamed, cf. #542). Thus, I think it should be possible to do this. The only possible disadvantage I see is a increased code complexity when we would need to check whether the mesh is really curvilinear or whether we can get away with Cartesian coordinates. And we need some developer time, of course, which is always the most limiting resource... Would you be willing to lend us a hand?

I am not sure whether there are really computational advantages we could exploit for a special coordinate system such as cylindrical or spherical coordinates, except that the singularities will probably need some special treatment. @andrewwinters5000?

[andrewwinters5000]

Exploiting Cartesian can definitely expedite runs because all the mapping terms are constant. For cylindrical/spherical @ranocha is correct that handling the singularities becomes a non-issue, e.g. this is one motivation behind the cubed-sphere approach that is also under experimental development in Trixi.

More generally, because the cylindrical/spherical mappings are orthogonal, their metric terms, while not constant, might have some sparsity (or other form) than one could exploit to reduce computational cost. That, or one could write new volume/surface routines to approximate the PDEs directly in those coordinates, e.g. (r, \theta, z) or (r, \theta, \phi). Either option would involve a degree of developer time and increase the code complexity.

[stillyslalom]

I'm trying to finish a PhD on the experimental side and can't guarantee a ton of time commitment, but I like where you're taking this and will try to help out where & when I can.

[ranocha]

Sounds good to me. We will always be happy to help you getting started. Some first notes:

• The performance of the curved meshes is not necessarily bad (but the Cartesian TreeMesh can of course be faster). We will present more information and performance comparisons with other codes at JuliaCon.
• If you want to get started with the unstructured 2D mesh, we can help you to create a mesh using HOHQMesh.jl.
• Since you're working at a shock tube lab, I guess you will need some shock capturing mechanisms, e.g. VolumeIntegralShockCapturingHG. This one is currently only implemented for the TreeMesh. However, there are already papers on extensions to curved meshes (that we can point out to you), so it would be a great PR to port them to our curved mesh types.
• If you need adaptive mesh refinement (AMR), the P4estMesh that is currently developed could be a great fit for your needs. Of course, the shock capturing stuff needs to be ported as well and some performance tuning is necessary for this mesh type, since it is work in progress at the moment.

[stillyslalom]

After a bit of effort, I managed to get a simple shock tube calculation working with TreeMesh. I'll upstream a few necessary helper function definitions for 1D multicomponent Euler (totalgamma & density_pressure) into Trixi once I'm confident with the results. If there's broader interest, I could also contribute a plot recipe to generate x-t diagrams like the following for 1D calculations.

(this is a M=1.55 shock driven by nitrogen from the left, interacting first with a helium-acetone mixture followed by a layer of argon)

[sloede]

Very nice results @stillyslalom! I'm glad to see that the setup seems to work for you. If you're willing to share, it would also be interesting to compare your results to reference results.

Plot recipes are always welcome! From experience I know that it is tricky to make plotting both convenient and general enough that it works not just for a particular setup. I'd thus be interested to see which approach you took!

[stillyslalom]

I’ll gladly share my setup once I’m confident it’ll run without intervention on machines besides my own. The calculated bulk speed of the post-shock helium agrees within a few percent of 1D gas dynamics, which is promising. I had some issues with the positivity-preserving limiters (they seemed to have no effect) and I ended up needing to specify a nonzero initial density for all components in all regions, but that’s no major flaw.

Would you mind if I created a Trixi.jl channel in the julialang Zulip chat to handle topics like this? It’s less formal than a GitHub issue, but there’s no good venue at the moment for discussion of Trixi from the user-side.

[sloede]

I ended up needing to specify a nonzero initial density for all components in all regions, but that’s no major flaw.

Yes, zero density is not possible unless using a scheme that guarantees that there are no over-/undershoots or oscillations. I believe that even with limiters this is hard to achieve, but I am not an expert on this.

Would you mind if I created a Trixi.jl channel in the julialang Zulip chat to handle topics like this? It’s less formal than a GitHub issue, but there’s no good venue at the moment for discussion of Trixi from the user-side.

Absolutely, please go head! Please note that none of the Trixi core developers are currently active on Julia's Zulip workspace. However, we do have a Trixi-related Slack workspace we created for the purpose of having more dynamic conversations about longer-running issues. If you send me your email address, I'd happily invite you to it!

[jlchan]

I'm not a core dev, but the Zulip channel sounds like a great idea! Should we also mirror that with a channel in Julia Slack?

[sloede]

Haha, I think we answered within less than 10 seconds :-)

Should we also mirror that with a channel in Julia Slack?

Absolutely, we can do that too! The downside with having in-depth discussions on the Julia Slack is that messages typically disappear after what, 10 days (?), due to the limitations of the free Slack workspace and the high volume of messaging there. Thus it is hard to have conversations that are not finished within a few days, and impossible to look up stuff that happened a few weeks ago.

[stillyslalom]

I created a Zulip channel: https://julialang.zulipchat.com/#narrow/stream/293441-Trixi.2Ejl

[sloede]

@stillyslalom Please note that we have taken up your issue of establishing other means of communicating about Trixi, be it among users or with the developers. In the README.md there's now a link to sign up for the Trixi Slack workspace (something that existed before but had not been actively promoted).