Skip to content
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

Sort unstructured boundary conditions #583

Merged

Conversation

andrewwinters5000
Copy link
Member

Improve the performance and type stability of the calc_boundary_flux of the unstructured solver. Addresses part of #542

@codecov
Copy link

codecov bot commented May 20, 2021

Codecov Report

Merging #583 (28f9e59) into main (99a7e28) will decrease coverage by 0.00%.
The diff coverage is 88.46%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #583      +/-   ##
==========================================
- Coverage   93.14%   93.14%   -0.01%     
==========================================
  Files         138      139       +1     
  Lines       14082    14111      +29     
==========================================
+ Hits        13117    13143      +26     
- Misses        965      968       +3     
Flag Coverage Δ
unittests 93.14% <88.46%> (-0.01%) ⬇️

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

Impacted Files Coverage Δ
src/equations/compressible_euler_2d.jl 94.33% <ø> (-0.01%) ⬇️
src/solvers/dg_unstructured_quad/dg.jl 75.00% <ø> (ø)
...emidiscretization/semidiscretization_hyperbolic.jl 89.01% <66.66%> (+0.37%) ⬆️
src/solvers/dg_unstructured_quad/dg_2d.jl 95.89% <90.47%> (-1.89%) ⬇️
src/mesh/mesh_io.jl 95.20% <100.00%> (+0.02%) ⬆️
...s/dg_unstructured_quad/sort_boundary_conditions.jl 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7bdcf0d...28f9e59. Read the comment docs.

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 for working on this! Please find below some comments. Feel free to ping me here or on Slack to discuss anything further.

src/semidiscretization/semidiscretization_hyperbolic.jl Outdated Show resolved Hide resolved
src/semidiscretization/semidiscretization_hyperbolic.jl Outdated Show resolved Hide resolved
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.

LGTM in general, with a minor comment. Once the other comments by @ranocha are resolved, this can be reviewed once more and then merged I think.

src/solvers/dg_unstructured_quad/dg_2d.jl Outdated Show resolved Hide resolved
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.

Looks already quite good. Just a minor comment and we can merge it from my side.

A general comment: Please consider using the GitHub feature to apply proposed changes directly. You would have saved both of us quite some time by doing that for #570 (comment) where I already fixed the problematic allocations I fixed in 875ad6c

@andrewwinters5000
Copy link
Member Author

Looks already quite good. Just a minor comment and we can merge it from my side.

A general comment: Please consider using the GitHub feature to apply proposed changes directly. You would have saved both of us quite some time by doing that for #570 (comment) where I already fixed the problematic allocations I fixed in 875ad6c

Okay, I will start using this feature. I used to like and combine the changes into a single commit to avoid cluttering the git log. But now that we use squash merge for PRs this is no longer an issue

@ranocha
Copy link
Member

ranocha commented May 21, 2021

Okay, I will start using this feature. I used to like and combine the changes into a single commit to avoid cluttering the git log. But now that we use squash merge for PRs this is no longer an issue

You can go to the "Files changed" section at the top and select something like "Add suggestion to batch" for all of them. Then, you can commit them in one batch/commit.

@ranocha ranocha enabled auto-merge (squash) May 21, 2021 13:17
@andrewwinters5000
Copy link
Member Author

You can go to the "Files changed" section at the top and select something like "Add suggestion to batch" for all of them. Then, you can commit them in one batch/commit.

Good to know. I will make sure I use this in the future

Comment on lines +249 to +251
# recursively call this method with the unprocessed boundary types
calc_boundary_flux_by_type!(cache, t, remaining_boundary_conditions,
remaining_boundary_condition_indices, mesh, equations, dg)
Copy link
Member

Choose a reason for hiding this comment

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

TBH, I don't really like these fancy lisp-style iterations unless explicitly required for performance reasons. I am not sure if this was benchmarked or not, but it makes the code harder to read and understand (IMHO, almost always does). No objections against using it here, but if we can get away without these constructs except for some extremely critical cases, I'd appreciate it.

@ranocha ranocha disabled auto-merge May 21, 2021 15:48
@ranocha ranocha merged commit 84674be into trixi-framework:main May 21, 2021
@efaulhaber
Copy link
Member

The changes in this PR seem to add some more complexity. How does the performance compare to the stuff benchmarked by @ranocha in #573?

@sloede
Copy link
Member

sloede commented May 21, 2021

It actually improves the performance, according to some benchmarks shown to me by @andrewwinters5000

@ranocha
Copy link
Member

ranocha commented May 22, 2021

The high-level overview: The first version implemented by @andrewwinters5000 payed the price of dynamic (runtime) dispatch (type instability) for every node on every boundary when at least two different BCs were used. My PR reduced that to runtime dispatch once per boundary. This PR fixed the underlying type instability completely, removing the cost of dynamic dispatch.

@sloede
Copy link
Member

sloede commented May 22, 2021

I'm still surprised though that you can see the difference between the second and third versions. Intuitively, I would've thought this should be negligible.

@ranocha
Copy link
Member

ranocha commented May 22, 2021

I'm still surprised though that you can see the difference between the second and third versions. Intuitively, I would've thought this should be negligible.

It had less impact, that's true. A bigger performance improvement came from

A general comment: Please consider using the GitHub feature to apply proposed changes directly. You would have saved both of us quite some time by doing that for #570 (comment) where I already fixed the problematic allocations I fixed in 875ad6c

Nevertheless, I think it's good to avoid type instabilities and train people to get used to some of these design choices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants