Skip to content

Should trixi_include work recursively? #37

@efaulhaber

Description

@efaulhaber

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

  1. make trixi_include recursive,
  2. add an option trixi_include(..., recursive = true), or
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions