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
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!
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.
As @sloede 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.
