Specify Callback Argument Type in init Functions in ODE solvers (2N, 3Sstar, PairedExplicitRK, SSP)

[warisa-r]

This pull request improves type safety and clarity in the init functions of various integrator methods that are updated per issue #1886 by specifying the argument type for callback, according to @JoshuaLampert suggestion in #2008. The callback parameter, which can either be a CallbackSet or Nothing, is now explicitly typed as Union{CallbackSet, Nothing}.

[github-actions]

Review checklist

This checklist is meant to assist creators of PRs (to let them know what reviewers will typically look for) and reviewers (to guide them in a structured review process). Items do not need to be checked explicitly for a PR to be eligible for merging.

Purpose and scope

• The PR has a single goal that is clear from the PR title and/or description.
• All code changes represent a single set of modifications that logically belong together.
• No more than 500 lines of code are changed or there is no obvious way to split the PR into multiple PRs.

Code quality

• The code can be understood easily.
• Newly introduced names for variables etc. are self-descriptive and consistent with existing naming conventions.
• There are no redundancies that can be removed by simple modularization/refactoring.
• There are no leftover debug statements or commented code sections.
• The code adheres to our conventions and style guide, and to the Julia guidelines.

Documentation

• New functions and types are documented with a docstring or top-level comment.
• Relevant publications are referenced in docstrings (see example for formatting).
• Inline comments are used to document longer or unusual code sections.
• Comments describe intent ("why?") and not just functionality ("what?").
• If the PR introduces a significant change or new feature, it is documented in NEWS.md with its PR number.

Testing

• The PR passes all tests.
• New or modified lines of code are covered by tests.
• New or modified tests run in less then 10 seconds.

Performance

• There are no type instabilities or memory allocations in performance-critical parts.
• If the PR intent is to improve performance, before/after time measurements are posted in the PR.

Verification

• The correctness of the code was verified using appropriate tests.
• If new equations/methods are added, a convergence test has been run and the results
  are posted in the PR.

Created with ❤️ by the Trixi.jl community.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 96.25%. Comparing base (e1aabb3) to head (2c8f2e5).

Files	Patch %	Lines
src/time_integration/methods_2N.jl	0.00%	1 Missing ⚠️
src/time_integration/methods_3Sstar.jl	0.00%	1 Missing ⚠️
src/time_integration/methods_SSP.jl	0.00%	1 Missing ⚠️
...ation/paired_explicit_runge_kutta/methods_PERK2.jl	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2026      +/-   ##
==========================================
+ Coverage   96.23%   96.25%   +0.02%     
==========================================
  Files         462      462              
  Lines       37084    37076       -8     
==========================================
  Hits        35687    35687              
+ Misses       1397     1389       -8     

Flag	Coverage Δ
unittests	96.25% <0.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JoshuaLampert]

Thanks, could you maybe also make more precise error messages regarding the continuous callbacks similar to #2008 (comment)? Also I think it would be better to throw an ArgumentError instead just throwing a generic error.

[warisa-r]

@JoshuaLampert By throwing an ArgumentError, do you mean by bringing back elseif and basically doing this?

if callback isa CallbackSet
        foreach(callback.continuous_callbacks) do cb
            error("Continuous callbacks are unsupported with the low-storage RK method (Carpenter, Kennedy 1994, 4th order, Solution 3).")
        end
        foreach(callback.discrete_callbacks) do cb
            cb.initialize(cb, integrator.u, integrator.t, integrator)
        end
    elseif !isnothing(callbacks)
        throw(ArgumentError("Invalid callback type. Expected CallbackSet or nothing."))
    end

Would that really be necessary since by this we are bringing back the redundant elseif? Since the current approach already throw this kind error: ERROR: LoadError: TypeError: in keyword argument callback, expected Union{Nothing, CallbackSet}, got a value of type Int64 which in my opinion already is sort of enough to let the user knows what has gone wrong. Or am I misunderstanding something?

[JoshuaLampert]

Yes, you are totally right. I didn't want to bring back the elseif. My suggestion with the ArgumentError was also regarding the continuous callbacks, where a generic error is used. Sorry for not being clear enough.

[warisa-r]

Got it! Thank you for the explanation.

[JoshuaLampert]

Thanks! What about

Trixi.jl/src/time_integration/methods_SSP.jl

Lines 158 to 167 in 9d8aac9

	if callback isa CallbackSet
	foreach(callback.continuous_callbacks) do cb
	error("unsupported")
	end
	foreach(callback.discrete_callbacks) do cb
	cb.initialize(cb, integrator.u, integrator.t, integrator)
	end
	elseif !isnothing(callback)
	error("unsupported")
	end

[JoshuaLampert]

I think the SSP method was also not covered in #1975. Is there a reason for that?

[warisa-r]

You are right in that SSP method isn't covered at all. I personally am also not sure why but I just left it out since I wasn't instructed to make any changes there. But according to the issue #1886 s title, SSP method should also been updated right? @DanielDoehring

[DanielDoehring]

Hm the SSP one is a bit different as it heavily relies on stage callbacks, which is not supported by the the standard OrdinaryDiffEq.jl method. But @bennibolm is the guy to ask on this matter.

So from my side this looks alright!

[JoshuaLampert]

Ok, if SSP is conceptually different to the others it's probably fine to have ignored it in #1975, but from what I can tell at least the changes from this PR also apply to the SSP method as well. At least the code block from this comment is pretty much the same as the corresponding code block in the other integrators. Thus, if you don't object @DanielDoehring I would also opt for applying the changes from this PR to the SSP method in order to keep consistency.

[DanielDoehring]

Yeah I guess we should make the error messages more similar.

[JoshuaLampert]

LGTM. Thanks!