-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Trixi.jl example simulations contain a lot of duplicate code because many elixirs are almost identical.
In TrixiParticles.jl, we tried to avoid this by recursively calling trixi_include
.
For example, we have a 3D version of a 2D example file, which looks like this:
using TrixiParticles
trixi_include(@__MODULE__,
joinpath(examples_dir(), "fluid", "hydrostatic_water_column_2d.jl"),
fluid_particle_spacing=0.05, initial_fluid_size=(1.0, 1.0, 0.9),
tank_size=(1.0, 1.0, 1.2), acceleration=(0.0, 0.0, -9.81),
smoothing_kernel=SchoenbergCubicSplineKernel{3}(), tspan=(0.0, 1.0),
maxiters=10^5, fluid_density_calculator=ContinuityDensity(),
clip_negative_pressure=false)
In this case, defining 3D fluid and tank sizes, 3D acceleration and a 3D kernel are necessary to make the simulation 3D.
The other kwargs fluid_particle_spacing
, tspan
, maxiters
, fluid_density_calculator
and clip_negative_pressure
are defining the same values as in the 2D file. We only added them to be able to overwrite these assignments when including the 3D file:
trixi_include(file_3d, fluid_particle_spacing=0.02)
It would be very convenient to either
- make
trixi_include
recursive, - add an option
trixi_include(..., recursive = true)
, or - add a macro
trixi_include_recursive
.
Option 2 conflicts with overwriting assignments with the same name recursive
.
Option 3 is a bit awkward.
Is there any reason against option 1?
I already implemented the logic for a recursive macro in #35.