Clarifying MMS source time in first-order dual-time stepping: uniform analytic reproducer

[Unjuno]

I have a small manufactured-solution reproducer and would like to clarify the intended time contract of GetMMSSourceTerm in single-zone first-order dual-time stepping. Is the callback intentionally evaluated at the old physical time, or should it receive the time of the updated solution?

This is related to the temporal-verification topic in discussion #1441, but isolates a spatially uniform, time-dependent source. I am not claiming that SU2's time integrator is inconsistent: both recurrences below are first-order consistent.

Analytic control

On a periodic cube use INC_NAVIER_STOKES, constant density 1, viscosity 0.01, energy disabled, and

u(t,x) = (1+t^2, 0, 0), p=0, f(t,x)=(2t,0,0).

All spatial derivatives vanish, so the PDE reduces to du_x/dt=2t. Initialize u_x=1 at time zero. After k updates of size h:

• Source at (k-1)h: U_k = 1+h^2*k*(k-1).
• Source at kh (fully backward Euler): U_k = 1+h^2*k*(k+1).
• Continuous exact value: 1+(kh)^2.

Neither discrete recurrence is the exact continuous solution at finite h.

Observed behavior

With the unmodified driver and source assembly in v8.5.0, commit 12eb826f049ef7f67df974dfcb44cf36ee07c0f8, the custom USER_DEFINED_SOLUTION control matches the old-time recurrence at every step within 2.7e-11. All four reported residuals are below 10^-10 at each update.

h	updates	final U_x	final history Cur_Time
0.1	5	1.200000000002	0.4
0.05	10	1.224999999997	0.45
0.025	20	1.237499999998	0.475

A diagnostic intervention changing only the single-zone SetPhysicalTime argument from TimeIter*h to (TimeIter+1)*h switches the results to the next-time recurrence within the same tolerance. This is a causal check, not a proposed general fix: restart, multizone, moving-grid and second-order behavior have not been tested.

Source inspection of master bc15466602a687d6fb796d5df7a12ce3fde0949a still shows the same time assignment and MMS consumer. I have not rerun a fresh master executable.

Reproducer and environment

Fixed evidence commit:

• Build and run instructions, including the custom analytic helper.
• Baseline raw cases and per-step diagnostics.
• Intervention cases.

Each archive contains the config, 4³-element periodic mesh, restart fields, history, logs, command and exit code. Linux arm64 Ubuntu 24.04 container, GCC 13.3.0, double precision, MPI disabled, two OpenMP threads. Source archives and image IDs are recorded.

Would it be useful to document this callback/output time convention and add this uniform transient MMS as a regression case? If the old-time evaluation is intentional, an explicit example would help users avoid comparing an updated state against a reference at the displayed old time. If the intended callback time is the updated time, a fix would need to review all consumers and time schemes rather than applying the diagnostic edit blindly.

[sbryngelson]

Yeah, I think your diagnosis is right.

At the master commit you linked, the single-zone driver sets PhysicalTime = TimeIter * dt during Preprocess. That same value is then passed to GetMMSSourceTerm, while the dual-time residual treats the current iterate as U^{n+1} and forms either the BDF1 or BDF2 time derivative against the stored previous states (residual assembly).

So for a nonautonomous MMS source, the current sequence is basically

solve for U^{n+1} using f(t_n),

which gives exactly the old-time recurrence you measured. It is still first-order consistent under DT_STEPPING_1ST, so I would not call the integrator inconsistent, but it is not a backward Euler evaluation of the time-dependent forcing.

The potentially more important case is DT_STEPPING_2ND. The state derivative there is BDF2, but if the forcing is still evaluated at t_n, then

f(t_{n+1}) - f(t_n) = O(dt),

so the lagged forcing can reduce the temporal convergence to first order for a genuinely time-dependent source. I would include both first- and second-order dual-time cases in the regression.

I would avoid treating the (TimeIter + 1) * dt edit as the complete fix. PhysicalTime is used for more than the source term: it is also passed into the verification-solution error calculation and time-dependent verification boundary states. Globally advancing it may fix this reproducer while changing output and other semantics elsewhere.

My preference would be to define the time levels explicitly. something like stored-state time versus target/solution time—and use the target time for MMS source and boundary evaluation. Then the output and restart paths can keep whichever convention they require.

tldr; yes, the current source explains your observed recurrence, and the uniform transient MMS case looks like a good regression test. The remaining maintainer question is whether the old-time source evaluation was intentional or is just an ambiguous physical-time convention.