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

AMR: do not enforce 2:1 balance in normal direction #6058

Merged
merged 1 commit into from
Jun 5, 2024

Conversation

kidder
Copy link
Member

@kidder kidder commented Jun 4, 2024

Proposed changes

Remove requirement that h-refinement must have 2:1 balance in the direction normal to faces.

Upgrade instructions

In input files that use AMR, you will need to add EnforceTwoToOneBalanceInNormalDirection: true to the list of Policies

Code review checklist

  • The code is documented and the documentation renders correctly. Run
    make doc to generate the documentation locally into BUILD_DIR/docs/html.
    Then open index.html.
  • The code follows the stylistic and code quality guidelines listed in the
    code review guide.
  • The PR lists upgrade instructions and is labeled bugfix or
    new feature if appropriate.

Further comments

@kidder
Copy link
Member Author

kidder commented Jun 4, 2024

@nilsvu here is the unfinished (and untested) branch for what you asked about

@kidder kidder marked this pull request as ready for review June 4, 2024 17:39
@kidder
Copy link
Member Author

kidder commented Jun 4, 2024

@nilsvu this is now ready for review. It did not cause any problems when I ran the RandomAmr executables.

Copy link
Member

@nilsvu nilsvu 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! Thanks for adding this.

@@ -133,6 +133,7 @@ Amr:
Verbosity: Verbose
Criteria: []
Policies:
EnforceTwoToOneBalanceInNormalDirection: true
Copy link
Member

Choose a reason for hiding this comment

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

Maybe set all these options to false? To me at least that's the expected behavior of AMR. Do we even have a use case for true?

Copy link
Member Author

Choose a reason for hiding this comment

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

I set them to true to reproduce previous behavior. Until setting them to false is more extensively tested, I'd rather keep them true for now.

Copy link
Member

Choose a reason for hiding this comment

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

Ok Im just worried that this will remain true and propagate to many input files and people will get unexpected behavior when trying AMR

Copy link
Member

Choose a reason for hiding this comment

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

I think in evolution problems we probably want it true. Geoffrey had issues if the grid size changed too much form one element to the next in the normal direction to the interface.

Copy link
Member

Choose a reason for hiding this comment

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

That's actually what I'm trying to prevent as well, in a domain that has differently sized blocks. For example, think of the thermal noise problem with thin layers on top of a substrate. You want to h-refine the substrate multiple times in z-direction, but each layer stays at h-refinement level 0.

Anyway, we can merge the PR like this and just have to keep in mind to experiment with this option.

@nilsvu nilsvu merged commit 6219c51 into sxs-collaboration:develop Jun 5, 2024
22 checks passed
@kidder kidder deleted the amr_limits branch August 7, 2024 14:26
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