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

Adding bittree interface to improve regridding performance in octree mode #3555

Merged
merged 10 commits into from
Oct 1, 2023

Conversation

akashdhruv
Copy link
Contributor

@akashdhruv akashdhruv commented Sep 18, 2023

Summary

This PR introduces dependency on Bittree library to improve regridding performance in octree mode.

Additional background

Testing and development of this feature is done in sync with Flash-X and is recorded in this reproducibility capsule. This PR is primarily created to consolidate development work and avoid creating multiple branches. At present using AMReX+Bittree improves regridding performance by a factor of 2 at > 20000 ranks. We hope to improve performance further using a bittree-based distribution mapping and therefore adding a new function AmrMesh::MakeDistributionMap as a place-holder.

Continuation of #2893 and #3547

Checklist

The proposed changes:

  • fix a bug or incorrect behavior in AMReX
  • add new capabilities to AMReX
  • changes answers in the test suite to more than roundoff level
  • are likely to significantly affect the results of downstream AMReX users
  • include documentation in the code and/or rst files, if appropriate

@WeiqunZhang WeiqunZhang self-requested a review September 18, 2023 18:20
@WeiqunZhang WeiqunZhang self-assigned this Sep 18, 2023
@akashdhruv akashdhruv force-pushed the bt-merge branch 5 times, most recently from 8e3cb73 to 74c5b5e Compare September 21, 2023 14:21
Copy link
Member

@WeiqunZhang WeiqunZhang left a comment

Choose a reason for hiding this comment

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

I will add a CI after this a merged.

Src/AmrCore/AMReX_AmrMesh.H Outdated Show resolved Hide resolved
Src/AmrCore/AMReX_AmrMesh.H Outdated Show resolved Hide resolved
Src/AmrCore/AMReX_AmrMesh.cpp Outdated Show resolved Hide resolved
Src/AmrCore/AMReX_AmrMesh.cpp Outdated Show resolved Hide resolved
Src/AmrCore/AMReX_AmrMesh.cpp Outdated Show resolved Hide resolved
Src/AmrCore/AMReX_AmrMesh.cpp Outdated Show resolved Hide resolved
@WeiqunZhang
Copy link
Member

I have run the test at amrex/Tests/Amr/Advection_AmrCore/Exec. It works as expected. However, the grids generated are not very efficient.

phi_plt00080_bittree
This is a picture from a run using bittree.

phi_plt00080_native
This is from a run using the native non-tree mode. The area covered by level 1 grids is much smaller.

@akashdhruv
Copy link
Contributor Author

akashdhruv commented Sep 28, 2023

I have run the test at amrex/Tests/Amr/Advection_AmrCore/Exec. It works as expected. However, the grids generated are not very efficient.

The area covered by level 1 grids is much smaller.

I think the refine-derefine criteria maybe too strict. I can look into this after the merge and create a follow-up PR

@kweide
Copy link
Contributor

kweide commented Sep 29, 2023

the grids generated are not very efficient.

I think we cannot do much better, given the octtree-mimicking parameters that we are using (and have been using way before Bittree) in Flash-X for the AMR/Amrex Grid implementation:

  ! Setup AMReX in octree mode
  call pp_amr%add   ("max_grid_size_x",     NXB)
  call pp_amr%add   ("max_grid_size_y",     NYB)
  call pp_amr%add   ("max_grid_size_z",     NZB)
  call pp_amr%add   ("blocking_factor_x", 2*NXB)
  call pp_amr%add   ("blocking_factor_y", 2*NYB)
  call pp_amr%add   ("blocking_factor_z", 2*NZB)
  call pp_amr%add   ("refine_grid_layout", 0)
  call pp_amr%add   ("grid_eff",  1.0)

  ! According to Weiqun n_proper=1 is an appropriate setting that will result in
  ! correct nesting.
  call pp_amr%add("n_proper", 1)

This is from our gr_amrexInit.F90. Maybe not all the lines are relevant here, maybe only the first 6 are.

(I think at one point at least I understood how the max_grid_size_ and blocking_factor_ AMReX parameters work, and why they have to be set this way in order to limit refinement patters to the octtree-ish ones that can be generated by PARAMESH.)

@WeiqunZhang WeiqunZhang merged commit 8515ea8 into AMReX-Codes:development Oct 1, 2023
65 of 67 checks passed
guj pushed a commit to guj/amrex that referenced this pull request Dec 13, 2023
…mode (AMReX-Codes#3555)

## Summary

This PR introduces dependency on [Bittree
library](https://github.com/Flash-X/Bittree) to improve regridding
performance in octree mode.

## Additional background

Testing and development of this feature is done in sync with Flash-X and
is recorded in this [reproducibility
capsule](https://github.com/Lab-Notebooks/AMReX-Bittree-Performance).
This PR is primarily created to consolidate development work and avoid
creating multiple branches. At present using AMReX+Bittree improves
regridding performance [by a factor of
2](https://github.com/Lab-Notebooks/AMReX-Bittree-Performance/blob/14faa2212c4e5dba7fd99a6526c6937414f9c109/analysis/Performance.ipynb)
at > 20000 ranks. We hope to improve performance further using a
bittree-based distribution mapping and therefore adding a new function
`AmrMesh::MakeDistributionMap` as a place-holder.

Continuation of AMReX-Codes#2893 and AMReX-Codes#3547

## Checklist

The proposed changes:
- [ ] fix a bug or incorrect behavior in AMReX
- [x] add new capabilities to AMReX
- [ ] changes answers in the test suite to more than roundoff level
- [ ] are likely to significantly affect the results of downstream AMReX
users
- [ ] include documentation in the code and/or rst files, if appropriate

---------

Co-authored-by: Weiqun Zhang <[email protected]>
Co-authored-by: Tom Klosterman <https://github.com/tklos96>
@akashdhruv
Copy link
Contributor Author

akashdhruv commented Jan 4, 2024

phi_plt00080_bittree This is a picture from a run using bittree.

@WeiqunZhang Can you create a time evolution so we can see how derefinement logic is working? It maybe possible that derefinement logic is not very strict.

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.

3 participants