Skip to content

Restart from different polynomial degrees #2358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 48 commits into
base: main
Choose a base branch
from

Conversation

DanielDoehring
Copy link
Contributor

See point 1 in #2316

@DanielDoehring DanielDoehring added the enhancement New feature or request label Apr 10, 2025
Copy link
Contributor

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.


# Version for MPI-parallel I/O
function interpolate_restart_file!(u, file, slice,
mesh, equations, dg, cache,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not add the dispatch on the mesh here as it should not be necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless it does not work for DGMulti?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this only works for Cartesian elements, right? For curved elements you'd need to include the grid metrics in the interpolation/projection step, IIRC (cc @andrewwinters5000 )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yeah true - I restrict this to DGSEM for now.

Good point - I though I am in safe waters as everything happens on the reference element, but maybe I need something like this?

# Loop over all elements in old container and scale the old solution by the Jacobian
# prior to projection
for old_element_id in 1:old_n_elements
for v in eachvariable(equations)
old_u[v, .., old_element_id] .= (old_u[v, .., old_element_id] ./
old_inverse_jacobian[..,
old_element_id])
end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I tested this with the 2D elixir_advection_unstructured_flag where I increase the base polydeg from 3 to 4 and then restart the subsequent run with polydeg = 3 (This is required since the mesh has polydeg 3).

This is the error report for "uniform" refinement:

 L2 error:       5.43210258e-04
 Linf error:     7.61325588e-03
 
 L2 error:       4.81669631e-05
 Linf error:     7.53667941e-04
 
 L2 error:       3.98543153e-06
 Linf error:     8.58091296e-05
 
 L2 error:       3.11114766e-07
 Linf error:     6.82719964e-06

which is not quite 4th order, but certainly more than 3rd order.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it would be good if @andrewwinters5000 could make a statement here :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this should be okay to have a lower polydeg for the mesh compared to the solver. But your projections will need to take the Jacobians into account. In the mapped coordinates it is in fact the quantity J*u that is conserved and not simply u. However, on static meshes this fact is hidden and the Jacobian is usually divided off for convenience.

Copy link
Contributor Author

@DanielDoehring DanielDoehring May 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I would need to do something like

$$u_\mathrm{new} = J_\mathrm{new} J^{-1}_\mathrm{old} u_\mathrm{old}$$

here?

Copy link

codecov bot commented Apr 10, 2025

Codecov Report

Attention: Patch coverage is 97.27273% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.74%. Comparing base (31e3d56) to head (c756203).
Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
src/callbacks_step/save_restart_dg.jl 96.63% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2358      +/-   ##
==========================================
- Coverage   96.80%   91.74%   -5.06%     
==========================================
  Files         494      494              
  Lines       40825    40905      +80     
==========================================
- Hits        39518    37525    -1993     
- Misses       1307     3380    +2073     
Flag Coverage Δ
unittests 91.74% <97.27%> (-5.06%) ⬇️

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.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@DanielDoehring DanielDoehring marked this pull request as ready for review April 10, 2025 13:25
@DanielDoehring DanielDoehring requested a review from SimonCan April 10, 2025 13:27
@ranocha
Copy link
Member

ranocha commented Apr 16, 2025

What is the status of this PR - ready for a review by @sloede or myself or would you like to change something based on the discussion above?

@DanielDoehring
Copy link
Contributor Author

I would wait for @SimonCan to do a first review, since he originally implemented the restarting mechanism. Other than that, I am of course grateful for being pointed to any flaws you immediately observe :)

@ranocha
Copy link
Member

ranocha commented Apr 16, 2025

Great, thanks. Please feel free to ping me when Simon is done with his review.

SimonCan
SimonCan previously approved these changes Apr 17, 2025
Copy link
Contributor

@SimonCan SimonCan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me now.

Copy link
Member

@sloede sloede left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't reviewed the parallel part yet, but I wanted to get these comments out before the Easter break.

Overall nice idea!


# Version for MPI-parallel I/O
function interpolate_restart_file!(u, file, slice,
mesh, equations, dg, cache,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless it does not work for DGMulti?


# Version for MPI-parallel I/O
function interpolate_restart_file!(u, file, slice,
mesh, equations, dg, cache,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this only works for Cartesian elements, right? For curved elements you'd need to include the grid metrics in the interpolation/projection step, IIRC (cc @andrewwinters5000 )

Comment on lines +104 to +107
# NOTE: Normally we would also need to exchange the `AnalysisCallback` when changing the
# semidiscretization. This, however, leads in the test environment to a confusing error
# report, as the error report from the simulation is different from the one from the test environment.
# Thus, we do not exchange the `AnalysisCallback` here.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these even valid error measures anymore then? I mean, if the poldeg of the solver and the analysis callback do not match?

Copy link
Contributor Author

@DanielDoehring DanielDoehring Apr 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, somewhat I guess? But in the tests we do not really care about the meaning of the numbers but more that there are some numbers at all (which stay constant over development), right?

semi = SemidiscretizationHyperbolic(mesh, equations, initial_condition, solver,
boundary_conditions = boundary_conditions)

ode = semidiscretize(semi, tspan, restart_filename)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a keyword to semidiscretize to explicitly allow polydeg conversion (i.e., conversely to throw an error if it is missing)? I am slightly worried about people accidentally restarting simulations at different polydegs and then wondering what went wrong. Something like

Suggested change
ode = semidiscretize(semi, tspan, restart_filename)
ode = semidiscretize(semi, tspan, restart_filename; allow_polydeg_conversion=true)

maybe. Or is this too much hand-holding for the users?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong feelings about this. One thing that comes to my mind is that we should throw a warning in the AnalysisCallback if the polydegs do not "match"

JoshuaLampert
JoshuaLampert previously approved these changes Apr 25, 2025
Copy link
Member

@JoshuaLampert JoshuaLampert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once the final conversations are resolved.

@ranocha ranocha requested a review from sloede April 25, 2025 13:31
@DanielDoehring
Copy link
Contributor Author

LGTM once the final conversations are resolved.

Thanks for your input, Joshua!

@DanielDoehring DanielDoehring requested a review from ranocha May 5, 2025 08:34
@DanielDoehring
Copy link
Contributor Author

Could we get going again here? My feature PRs start piling up again
@SimonCan @sloede

SimonCan
SimonCan previously approved these changes May 26, 2025
Copy link
Contributor

@SimonCan SimonCan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Copy link
Member

@ranocha ranocha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! I just have a minor suggestion. Does anybody know whether @sloede wants to review the PR after requesting changes some time ago?

Copy link
Member

@andrewwinters5000 andrewwinters5000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some suggested cleanup of the docstrings. One thing that occurred to me, an error should get thrown if the attempted new solver polydeg is less than the existing mesh_polydeg as one cannot guarantee free-stream preservation in this case.


# Version for MPI-parallel I/O
function interpolate_restart_file!(u, file, slice,
mesh, equations, dg, cache,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this should be okay to have a lower polydeg for the mesh compared to the solver. But your projections will need to take the Jacobians into account. In the mapped coordinates it is in fact the quantity J*u that is conserved and not simply u. However, on static meshes this fact is hidden and the Jacobian is usually divided off for convenience.

@DanielDoehring DanielDoehring marked this pull request as draft May 28, 2025 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants