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 a dynamic stress (wave model) to wall_models #1233

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

ayalamanuel
Copy link

@ayalamanuel ayalamanuel commented Sep 4, 2024

Summary

We have introduced a dynamic stress as a wall model. the dynamic stress calculates the stress due to waves. a new struct was implemented in ShearStressSimple.H where the wave stress is calculated. a new header (MOSD.H) was created with the calculations of the stress. the WallFunction.cpp has been modified accordingly.

Unit testing (test_mosd.cpp) and regression testing (channel_mosd.inp) using CPU has been done and added. The documentation of the model has also been added in the inputs_Boundary_conditions.rst file.

Pull request type

Please check the type of change introduced:

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

Checklist

The following is included:

  • new unit-test(s)
  • new regression test(s)
  • documentation for new capability

This PR was tested by running:

  • the unit tests
    • on GPU
    • on CPU
  • the regression tests
    • on GPU
    • on CPU

Additional background

Issue Number:

Copy link
Contributor

@marchdf marchdf left a comment

Choose a reason for hiding this comment

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

Quick list of things to do (I am sure you are working on these):

  • documentation
  • reg test
  • unit test

I can look at the PR in detail later this week. Thank you for working on this!

@gdeskos gdeskos self-requested a review September 4, 2024 19:57
@marchdf
Copy link
Contributor

marchdf commented Sep 11, 2024

@ayalamanuel do you have any updates on this?

@ayalamanuel
Copy link
Author

@marchdf Old files have been updated. Unit test, regression test and documentation have been added. Thanks!

amr-wind/boundary_conditions/wall_models/MOSD.H Outdated Show resolved Hide resolved
amr-wind/boundary_conditions/wall_models/MOSD.H Outdated Show resolved Hide resolved
amr-wind/boundary_conditions/wall_models/MOSD.H Outdated Show resolved Hide resolved
amr-wind/boundary_conditions/wall_models/MOSD.H Outdated Show resolved Hide resolved
amr-wind/boundary_conditions/wall_models/WallFunction.cpp Outdated Show resolved Hide resolved
amr-wind/boundary_conditions/wall_models/WallFunction.cpp Outdated Show resolved Hide resolved
unit_tests/boundary_conditions/test_mosd.cpp Outdated Show resolved Hide resolved
@ayalamanuel
Copy link
Author

I've made the modifications to all the comments made @marchdf

docs/sphinx/user/inputs_Boundary_conditions.rst Outdated Show resolved Hide resolved
unit_tests/boundary_conditions/test_mosd.cpp Outdated Show resolved Hide resolved
unit_tests/boundary_conditions/test_mosd.cpp Outdated Show resolved Hide resolved
@marchdf
Copy link
Contributor

marchdf commented Sep 18, 2024

A meta comment here: to get past the CI check, the first thing you need to do is format your code. You can do that automatically with clang-format: https://exawind.github.io/amr-wind/developer/coding_guidelines.html#style-guide-recommendations

submods/amrex Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
bx.contains(amrex::IntVect(i, j, k_lo)));
AMREX_ALWAYS_ASSERT(
bx.contains(amrex::IntVect(i, j, k_hi)));
const amrex::Real z_diff = dx[0] - (k_lo + 0.5) * dx[2];
Copy link
Contributor

Choose a reason for hiding this comment

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

There is still the negative z_diff issue that I mentioned previously. This logic for interpolation needs to be more nuanced to handle several edge cases.

Copy link
Contributor

Choose a reason for hiding this comment

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

The issue stems from the fact that you're using floor a ratio of dx[0]/dx[2] and subsequently adding a 0.5 to this floor, I think the actual k_lo calculation should be floor(dx[0]/dx[2] - 0.5).

Please double check to ensure that this inequality is always true: (k_lo + 0.5) * dx[2] < dx[0] < (k_lo + 1 + 0.5)*dx[2], otherwise your interpolation will not work.

You're still operating under the assumption that dx[0] > dx[2] too, might want to check for that as well.

Copy link
Author

Choose a reason for hiding this comment

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

I agree. I just did some modifications to the interpolation to try to make it more general. I think it's a little bit convoluted but i understand why we need to do this.

Copy link
Contributor

@moprak-nrel moprak-nrel left a comment

Choose a reason for hiding this comment

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

I think the interpolation logic looks a lot better! Here's a few more minor comments on the interpolation

(z_interp - z_lo) / (z_hi - z_lo);
const amrex::Real u_low =
vold_arr(i, j, k_lo, 0);
const amrex::Real u_up =
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor comment, can we change these to u_lo and u_hi to be consistent with k_lo and k_hi? (Or k_low and k_hi).


// Check if the interpolation condition is
// satisfied
if (z_lo < z_interp && z_interp < z_hi) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be z_lo <= z_interp? Example dx[0] = 1.5 * dx[2]

tau.get_shear(
vv, wspd, u_dx, v_dx, xc, 1) /
mu * den(i, j, k);
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious, when do we expect this branch to occur?

@marchdf
Copy link
Contributor

marchdf commented Oct 9, 2024

Can I do anything to help push this through? We are super close I think.

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