Add auxiliary variables, part 1 by benegee · Pull Request #3008 · trixi-framework/Trixi.jl

benegee · 2026-05-12T19:21:42Z

Continuing #2348

As a first step, auxiliary variables are implemented for TreeMesh 2D. AcousticPerturbationEquations2DAuxVars demonstrates how auxiliary variables can be used instead of augmenting the solution state vector, as previously done, e.g., in AcousticPerturbationEquations2D.

Some comments:

Auxiliary variables could potentially be used everywhere in Trixi.jl, which makes infrastructural changes necessary almost everywhere. It usually boils down to querying have_aux_node_vars(equations) and using the result for multiple dispatch.
Specializations for have_aux_node_vars::True are added only for the 2D TreeMesh implementation in this PR. The code changes are trivial, usually just adding get_aux_node_vars or get_aux_surface_node_vars where get_node_vars or get_surface_node_vars were already called, and passing the resulting aux vars down, e.g. to flux computations.
A less trivial part is the setup of the aux vars in solvers/dgsem_tree/containers_2d.jl, although it mostly follows corresponding prolong2* functions.
A non-trivial part is the setup and usage of MPI interfaces, where the aux vars are directly evaluated on both sides and not communicated. This assumes the aux vars field is steady, never discontinuous.
A truly non-trivial part is the setup and use of mortars. So far, aux vars are always evaluated for the small mortar elements and these values are used on both sides of the mortar, unlike the usual variables, which also exist on the large elements and need to be interpolated to the small elements. Similar to the discussion in Add auxiliary variables #2348 (comment), an alternative interpolating version could be added.

Supersedes #2907

- add container for node and surface auxiliary variables - add initializer to SemidiscretizationHyperbolic - dispatch on have_auxiliary_node_vars for 2D TreeMesh rhs!

to demonstrate how auxiliary variables can be used instead of augmenting the solution state vector

ŕesults have to be identical to the corresponing AcousticPerturbationEquations2D results

benegee · 2026-05-15T09:12:14Z

All conflicts resolved. This is now ready for review.

Downstream tests are expected to fail because TrixiShallowWater.jl and TrixiAtmo.jl overwrite internal Trixi.jl functions, e.g. https://github.com/trixi-framework/TrixiShallowWater.jl/blob/14552f2fdd0df83dbc094d2700c9e37dfaeab037/src/solvers/dgsem_p4est/dg_2d.jl#L314 would now need an additional have_aux_node_vars argument.

MarcoArtiano

Thanks Benedict! That looks so interesting and great to have in Trixi. I have not made a review, but just left a few comments to understand better the infrastructure. I'm not actually sure if there are some problems or issues that could increase the complexity of the implementation.

MarcoArtiano · 2026-05-16T09:24:13Z

+###############################################################################
+# semidiscretization of the acoustic perturbation equations
+
+function auxiliary_variables_mean_values(x, equations)


Would it make sense (or be interesting) to compute first the initial condition and then pass also the initial condition u0 as a parameter to the auxiliary field function?

I see this would be convenient when e.g. setting up perturbations of a steady background state.

However, u0 is computed using compute_coefficients(t, semi), which takes a Semidiscretization object, right?

DanielDoehring · 2026-05-17T07:59:51Z

I suggest this splitting into multiple PRs, starting from 1D TreeMesh?

ranocha

Thanks for your efforts. How do you see the chances to allow discontinuities at interfaces?

ranocha · 2026-05-23T09:11:41Z

+    # constant auxiliary variables (mean state)
+    return global_mean_vars(equations)
+end


Does it really make sense to introduce this set of equations if the auxiliary variables are only given by some constants that are also stored in the equations? Could it be better to use something that appears to be less artificial, e.g., a 2D linear advection equation with variable velocity field? If it is required to be divergence free, a reasonable discretization can be a split form (but we can test the weak form as well, of course).

This is indeed not really useful; merely a proof of concept that can be compared to something in main as a sanity check.

Non trivial velocity fields would be more exciting. I like the swirling flow by LeVeque:

Although in this form it requires time dependent aux vars, which I added quick and dirty here

Trixi.jl/src/solvers/dgsem_tree/dg_2d.jl

Lines 125 to 128 in 9eea80c

# Recompute aux vars

@trixi_timeit_ext backend timer() "recompute aux vars" begin

recompute_aux_vars!(mesh, have_aux_node_vars(equations), equations, dg, cache,

t)

One could of course start with a time constant variant of it.

Nice example! Something like this with constant-in-time (but variable-in-space) velocity would already be nice to ensure that the non-constant case works as expected.

Done in examples/tree_2d_dgsem/elixir_advection_variable_swirling_flow.jl

ranocha · 2026-05-23T09:15:04Z

 function analyze(quantity, du, u, t, semi::AbstractSemidiscretization)
    mesh, equations, solver, cache = mesh_equations_solver_cache(semi)
-    return analyze(quantity, du, u, t, mesh, equations, solver, cache)
+    return analyze(quantity, du, u, t, mesh, have_aux_node_vars(equations), equations,
+                   solver, cache)
 end
-function analyze(quantity, du, u, t, mesh, equations, solver, cache)
+function analyze(quantity, du, u, t, mesh, have_aux_node_vars, equations, solver, cache)
    return integrate(quantity, u, mesh, equations, solver, cache, normalize = true)
 end


Do we acutally need the dispatch at this high level? It introduces some complexity here where I do not see the benefits of it. Would it be sufficient to extract the trait when it is required, e.g., for analyze(::typeof(entropy_timederivative), ... later?

I'm not sure.

I need the aux vars here:

Trixi.jl/src/callbacks_step/analysis_dg2d.jl

Lines 472 to 485 in 8909f98

function analyze(::typeof(entropy_timederivative), du, u, t,

mesh::Union{TreeMesh{2}, StructuredMesh{2}, StructuredMeshView{2},

UnstructuredMesh2D, P4estMesh{2}, T8codeMesh{2}},

have_aux_node_vars::True, equations, dg::DG, cache)

@unpack aux_node_vars = cache.aux_vars

# Calculate ∫(∂S/∂u ⋅ ∂u/∂t)dΩ

integrate_via_indices(u, mesh, equations, dg, cache,

du) do u, i, j, element, equations, dg, du

u_node = get_node_vars(u, equations, dg, i, j, element)

aux_node = get_aux_node_vars(aux_node_vars, equations, dg, i, j, element)

du_node = get_node_vars(du, equations, dg, i, j, element)

dot(cons2entropy(u_node, aux_node, equations), du_node)

end

end

Would I need to specialize integrate_via_indices and the anonymous function (defined by the do syntax). So far, I was not successful.

Can't you introduce the additional dispatch only for this method of analyze, e.g., something along the lines of

function analyze(::typeof(entropy_timederivative), du, u, t, mesh::Union{TreeMesh{2}, StructuredMesh{2}, StructuredMeshView{2}, UnstructuredMesh2D, P4estMesh{2}, T8codeMesh{2}}, equations, dg::DG, cache) # The entropy_timederivative may depend on auxiliary variables. return analyze(entropy_timederivative, du, u, t, mesh, have_aux_node_vars(equations), equations, dg, cache) end

and then the specialization you wrote above?

Yes, obviously... Thanks for the hint!

Co-authored-by: Hendrik Ranocha <ranocha@users.noreply.github.com>

…k/Trixi.jl into bg/feature-aux-vars-merge

benegee

Thanks a lot for your feedback! I could easily address most of the comments.

How do you see the chances to allow discontinuities at interfaces?

This is something to discuss!

I think this would be possible as well.

We can still define the interface as we see fit. This is the current call:

Trixi.jl/src/solvers/dgsem_tree/containers.jl

Line 199 in 9eea80c

aux_field(x_local, t, equations),

We could additionally pass the element. Or how would we usually "detect" an interface. How do we do it with initial conditions?
So far I used the assumption the aux vars be continuous to spare some MPI communication at the interfaces, and to use non-interpolated data at mortar interfaces (comment in containers_2d), but this could be adapted appropriately.

benegee · 2026-05-27T13:54:49Z

+    # constant auxiliary variables (mean state)
+    return global_mean_vars(equations)
+end


This is indeed not really useful; merely a proof of concept that can be compared to something in main as a sanity check.

Non trivial velocity fields would be more exciting. I like the swirling flow by LeVeque:

Although in this form it requires time dependent aux vars, which I added quick and dirty here

Trixi.jl/src/solvers/dgsem_tree/dg_2d.jl

Lines 125 to 128 in 9eea80c

# Recompute aux vars

@trixi_timeit_ext backend timer() "recompute aux vars" begin

recompute_aux_vars!(mesh, have_aux_node_vars(equations), equations, dg, cache,

t)

One could of course start with a time constant variant of it.

benegee · 2026-05-27T14:00:55Z

 function analyze(quantity, du, u, t, semi::AbstractSemidiscretization)
    mesh, equations, solver, cache = mesh_equations_solver_cache(semi)
-    return analyze(quantity, du, u, t, mesh, equations, solver, cache)
+    return analyze(quantity, du, u, t, mesh, have_aux_node_vars(equations), equations,
+                   solver, cache)
 end
-function analyze(quantity, du, u, t, mesh, equations, solver, cache)
+function analyze(quantity, du, u, t, mesh, have_aux_node_vars, equations, solver, cache)
    return integrate(quantity, u, mesh, equations, solver, cache, normalize = true)
 end


I'm not sure.

I need the aux vars here:

Trixi.jl/src/callbacks_step/analysis_dg2d.jl

Lines 472 to 485 in 8909f98

function analyze(::typeof(entropy_timederivative), du, u, t,

mesh::Union{TreeMesh{2}, StructuredMesh{2}, StructuredMeshView{2},

UnstructuredMesh2D, P4estMesh{2}, T8codeMesh{2}},

have_aux_node_vars::True, equations, dg::DG, cache)

@unpack aux_node_vars = cache.aux_vars

# Calculate ∫(∂S/∂u ⋅ ∂u/∂t)dΩ

integrate_via_indices(u, mesh, equations, dg, cache,

du) do u, i, j, element, equations, dg, du

u_node = get_node_vars(u, equations, dg, i, j, element)

aux_node = get_aux_node_vars(aux_node_vars, equations, dg, i, j, element)

du_node = get_node_vars(du, equations, dg, i, j, element)

dot(cons2entropy(u_node, aux_node, equations), du_node)

end

end

Would I need to specialize integrate_via_indices and the anonymous function (defined by the do syntax). So far, I was not successful.

…k/Trixi.jl into bg/feature-aux-vars-merge

tristanmontoya

The core implementation looks good, although if we can remove the trait and just use zero-length vectors without overhead like you mentioned here, that would probably be cleaner, assuming there's negligible overhead. My suggestions are basically just to add clearer documentation in places (see comments).

tristanmontoya · 2026-06-04T01:56:12Z

 function analyze(::typeof(entropy_timederivative), du, u, t,
-                 mesh::Union{TreeMesh{1}, StructuredMesh{1}}, equations,
-                 dg::Union{DGSEM, FDSBP}, cache)
+                 mesh::Union{TreeMesh{1}, StructuredMesh{1}},
+                 equations, dg::Union{DGSEM, FDSBP}, cache)


There are some lines in this PR that just seem to be formatting changes. Not a big deal but it makes the diff look a bit bigger than it actually is.

tristanmontoya · 2026-06-04T02:21:09Z

+Trait function determining whether `equations` need to access additional auxiliary
+variables.


I would give a more complete description of auxiliary variables here, or if you define it elsewhere, link it here. For example:

Suggested change

Trait function determining whether `equations` need to access additional auxiliary

variables.

Trait function determining whether auxiliary variables should be stored at each node

alongside the solution variables and used to compute the flux for `equations`. When

`True()`, the signature of [`flux`](@ref) becomes the following:

```

flux(u, aux_vars, orientation_or_normal_direction, equations)

```

The auxiliary variables are computed by passing an additional keyword argument

`aux_field` into [`SemidiscretizationHyperbolic`](@ref), where

`aux_field(x, equations)` returns an `SVector` of size `n_aux_node_vars(equations)`

at every point `x` in the spatial domain.

!!! warning "Experimental implementation"

The use of auxiliary variables is an experimental feature and may change in future

releases. Currently, only 2D `TreeMesh` is supported.

tristanmontoya · 2026-06-04T02:27:15Z

+which will be available, e.g., in flux computations. The current `equations` need to set
+`have_aux_node_vars to `True()` and `n_aux_node_vars` to the number of auxiliary variables
+per node. Upon refinement, `aux_field` will be called again to recompute the auxiliary variables.
+NOTE: This is experimental!


Suggested change

NOTE: This is experimental!

!!! warning "Experimental implementation"

The use of auxiliary variables is an experimental feature and may change in future

releases. Currently, only 2D `TreeMesh` is supported.

benegee added 30 commits April 3, 2025 17:45

add auxliary variables

2bd998a

- add container for node and surface auxiliary variables - add initializer to SemidiscretizationHyperbolic - dispatch on have_auxiliary_node_vars for 2D TreeMesh rhs!

add AcousticPerturbationEquations2DAuxVars

8b9b556

to demonstrate how auxiliary variables can be used instead of augmenting the solution state vector

add tests for AcousticPerturbationEquations2DAuxVars

d9d7054

ŕesults have to be identical to the corresponing AcousticPerturbationEquations2D results

format

060054a

extend 2D TreeMesh AMR for aux vars

88e7f12

add elixir and test for AMR with aux vars

15cea5c

adapt mehtod used in VisualizationCallback

fa33421

do not use VisualizationCallback

5f8891f

lets fix something

14ec2f5

and some more

1e03b7e

fix performance specilization testing

f429f9b

re-add slip wall BC

a59ce7e

make ParallelTreeMesh compatible

18305b7

format

6346829

p4est mpi interface flux

4be0151

generic flux_central and DissipationLocalLaxFriedrichs

087f507

Merge branch 'main' into bg/feature-aux-vars

9cec964

format

7170717

Merge branch 'main' into bg/feature-aux-vars

9d1020e

add comments to apply_solution_variables

d707495

rename *auxiliary*variables* -> *aux*vars*

ebe1b02

add comment that only TreeMesh2D is currently supported

0b2a08d

comment

14868f3

fmt

64b4f51

rename file as well

9de7add

add have_aux_node_vars to analysis callback

468a5db

renamed

1d739fd

Merge branch 'main' into bg/feature-aux-vars

1a4d0ac

rename init_auxiliary_surface_node_variables

2e19fe7

more aux renaming

258c5e4

benegee added 3 commits May 15, 2026 09:04

add TreeMesh2D aux vars test with MPI and AMR

8f3437c

fix

0b36ca3

removed part which are uncovered atm

9517e98

benegee marked this pull request as ready for review May 15, 2026 09:07

MarcoArtiano reviewed May 16, 2026

View reviewed changes

DanielDoehring added the enhancement New feature or request label May 17, 2026

ranocha reviewed May 23, 2026

View reviewed changes

benegee and others added 8 commits May 27, 2026 11:40

Merge branch 'main' into bg/feature-aux-vars-merge

540c829

Apply suggestions from code review

eaa1dfe

Co-authored-by: Hendrik Ranocha <ranocha@users.noreply.github.com>

Merge branch 'bg/feature-aux-vars-merge' of github.com:trixi-framewor…

a078ffb

…k/Trixi.jl into bg/feature-aux-vars-merge

revert to passing surface_flux_values

68071e4

extend news

e40e6b0

comment

9b4beb6

rename constant_speed to have_constant_speed

a896214

fixes

8909f98

benegee commented May 27, 2026

View reviewed changes

benegee and others added 7 commits June 2, 2026 16:03

extend NEWS comment

d7262a3

dispatch a lot less in analyze

82191a6

add LinearVariableScalarAdvectionEquation2D

bd27c1c

add boundary condition with aux vars

b0e4593

add test case for LinearVariableScalarAdvectionEquation2D

5971eda

simplify create_cache

29a66a9

Merge branch 'main' into bg/feature-aux-vars-merge

5057297

github-actions Bot reviewed Jun 2, 2026

View reviewed changes

benegee added 3 commits June 3, 2026 09:15

fmt

d1b8ac8

Merge branch 'bg/feature-aux-vars-merge' of github.com:trixi-framewor…

05e953c

…k/Trixi.jl into bg/feature-aux-vars-merge

Merge branch 'main' into bg/feature-aux-vars-merge

56b33c7

tristanmontoya requested changes Jun 4, 2026

View reviewed changes

	# Recompute aux vars
	@trixi_timeit_ext backend timer() "recompute aux vars" begin
	recompute_aux_vars!(mesh, have_aux_node_vars(equations), equations, dg, cache,
	t)

	function analyze(::typeof(entropy_timederivative), du, u, t,
	mesh::Union{TreeMesh{2}, StructuredMesh{2}, StructuredMeshView{2},
	UnstructuredMesh2D, P4estMesh{2}, T8codeMesh{2}},
	have_aux_node_vars::True, equations, dg::DG, cache)
	@unpack aux_node_vars = cache.aux_vars
	# Calculate ∫(∂S/∂u ⋅ ∂u/∂t)dΩ
	integrate_via_indices(u, mesh, equations, dg, cache,
	du) do u, i, j, element, equations, dg, du
	u_node = get_node_vars(u, equations, dg, i, j, element)
	aux_node = get_aux_node_vars(aux_node_vars, equations, dg, i, j, element)
	du_node = get_node_vars(du, equations, dg, i, j, element)
	dot(cons2entropy(u_node, aux_node, equations), du_node)
	end
	end

		Trait function determining whether `equations` need to access additional auxiliary
		variables.

-Trait function determining whether `equations` need to access additional auxiliary
-variables.
+Trait function determining whether auxiliary variables should be stored at each node
+alongside the solution variables and used to compute the flux for `equations`. When
+`True()`, the signature of [`flux`](@ref) becomes the following:
+```
+flux(u, aux_vars, orientation_or_normal_direction, equations)
+```
+The auxiliary variables are computed by passing an additional keyword argument
+`aux_field` into [`SemidiscretizationHyperbolic`](@ref), where
+`aux_field(x, equations)` returns an `SVector` of size `n_aux_node_vars(equations)`
+at every point `x` in the spatial domain.
+!!! warning "Experimental implementation"
+    The use of auxiliary variables is an experimental feature and may change in future
+    releases. Currently, only 2D `TreeMesh` is supported.

Conversation

benegee commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benegee commented May 15, 2026

Uh oh!

MarcoArtiano left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

DanielDoehring commented May 17, 2026

Uh oh!

ranocha left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

benegee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tristanmontoya left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

benegee commented May 12, 2026 •

edited

Loading

MarcoArtiano left a comment •

edited

Loading

tristanmontoya left a comment •

edited

Loading