[ANN] Trixi.jl: A tree-based numerical simulation framework for hyperbolic PDEs

Trixi.jl is a numerical simulation framework for hyperbolic conservation laws. A key objective for the framework is to be useful to both scientists and students. Therefore, next to having an extensible design with a fast implementation, Trixi is focused on being easy to use for new or inexperienced users, including the installation and postprocessing procedures. Its features include:

  • Hierarchical quadtree/octree grid with adaptive mesh refinement
  • Native support for 2D and 3D simulations
  • High-order accuracy in space in time
  • Nodal discontinuous Galerkin spectral element methods
    • Kinetic energy-preserving and entropy-stable split forms
    • Entropy-stable shock capturing
  • Explicit low-storage Runge-Kutta time integration
  • Square/cubic domains with periodic and Dirichlet boundary conditions
  • Multiple governing equations:
    • Compressible Euler equations
    • Magnetohydrodynamics equations
    • Hyperbolic diffusion equations for elliptic problems
    • Scalar advection
  • Multi-physics simulations
  • Shared-memory parallelization via multithreading
  • Visualization of results with Julia-only tools (2D) or ParaView/VisIt (2D/3D)

Simulation of self-gravitating Sedov blast wave with adaptive mesh refinement
Simulation of self-gravitating Sedov blast wave with adaptive mesh refinement (arXiv:2008.10593).

In case of questions, please feel free to create an issue. We are looking forward to feedback and/or potential scientific collaboration.


Do you have benchmarks vs DifferentialEquations?

I don’t think DiffEq.jl has support for multidimensional hyperbolic conservation laws. The closest existing tool in Julia is Oceananigans, which targets a very different problem domain (and is only really similar in that it’s a multidimensional fluids solver). I’d be interested in a benchmark against something like Flash or Pyranda.

I don’t quite understand the choice of .toml as a parameter format, which requires a separate .jl file for definition of initial conditions, when pure Julia could be used for both (which also adds flexibility/extensibility).

That said, very impressive to see DG/AMR implemented in Julia!


Indeed, the only overlap is on the timestepping, and we’re taking how to get that all on the common interface.


I second both claims!


A comparison with Flash is definitely on the agenda, maybe not just yet. The difficulty here is that you’re (at little bit at least) comparing apples with oranges. To make it a useful comparison, Trixi needs to learn a few more tricks first, I think (but we’re working on that…)

That one is easy to answer: The initiators of Trixi.jl come from the scientific computing/HPC/computational engineering world, where Fortran and C++ are still dominant. Thus when we started with Trixi about half a year ago, we made many initial design choices based on past experiences with traditional languages, including parameter files.

Since then, however, and mainly thanks to @ranocha, we have already started moving towards a much more Julian approach, such that, e.g., fluxes, initial conditions etc. can already be supplied by the user without having to modify Trixi’s sources. Obviously we are not there yet, but finding an easy-to-use pure Julian approach to setting up simulations and specifying parameters is high on the priority list for the Trixi infrastructure.


I think Oceananigans.jl sets a pretty good example with its input deck syntax. I’m most familiar with Pyranda’s behind-the-fence parent, Miranda, which uses Lua input decks to drive a Fortran code. You can specify pretty much any IC/BC/forcing terms as a set of user-created f(x, y, z, t) within the input deck. Those specifications don’t necessarily need to be your fixed set of primitives, either - just as you can specify range(1.0, stop=10, length=10) or range(1.0, stop=10, step=1), you can specify any closed set of the state variables and let the code calculate the necessary primitives via the EOS.

One of the keys is to take advantage of Julia’s multiple dispatch with parameterized structs to keep track of dimensionality, which avoids this sort of nested, string-based if-else block. Generally speaking, you should always prefer structs to strings for parameter specification, since the former makes precompilation and inference a lot easier.


Thanks a lot for you nice feedback!

As @michael wrote above, the usage of TOML (parameter) files is a legacy from previous monolithic simulation codes written in FORTRAN. We’ve questioned a lot of old practices from these days in #42 and will move towards a more Julian way. The way of setting up a simulation as in the example from Oceananigans.jl is exactly what we want to have. It’s good to know that you all (and others, see #150) encourage doing this!

Just adding on top of what people have said: indeed thinking of a computational code as a library rather than something that takes as input text files and produces text files simplifies life greatly, both for input (not having to write and maintain a parser) and for output (being able to inspect datastructures directly). We do that in DFTK for instance. Kwargs are pretty neat for specifying parameters.


Thanks again for all of your comments! We have rewritten Trixi.jl completely to make it more modular and Julian - we made the transition from “Trixi as a monolith” to “Trixi as a library” (search for PRs/commits/issues mentioning “Taal” in our repo). In particular, we got rid of TOML parameter files to set up simulations and replaced them by pure Julia code.
See our new announcement for further details.