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

Restructure and retest modinlet and moddriver. Improved modboundary. #68

Open
tomgrylls opened this issue Apr 3, 2020 · 4 comments
Open
Assignees
Labels
Milestone

Comments

@tomgrylls
Copy link
Contributor

Summary: Necessity to test modinlet. Potential to improve implementation of modinlet and moddriver within modstartup and modboundary. Potential to have consistent notation for all BC input parameters.

Initial thoughts:

  1. modinlet.f90 has not been used for a long time and requires testing to make sure it is still compatible with the latest version of the code.

  2. The implementation of both of these modules is outdated and not consistent with the desired structure of modboundary (moddriver was developed to follow the same implementation as modinlet). Examples include:

  • If BCxm is not equal to 1 then other boundary condition input parameters will be overwritten in modstartup.f90. Can these bits of code can be moved to the subroutine initboundary for clarity? Can the set of switches and cases be redefined so that input paramters are not overwritten?
  • The use of switches such as linoutflow and lper2inout requires revision. linoutflow is confirmed to work for the use of moddriver and is essential to changing the boundary conditions for pressure but its use elsewhere in the code requires revision.
  • The use of ubulk and uouttot (see Check the use of ubulk and uouttot #54 ). See ?.
  • Consistency of subroutines iosi, iohi, ioqi with inflow-outflow simulations and periodic simulations. Currently these are used when lateral momentum BCs are periodic but subroutine iolet is used instead otherwise.
  1. Other related improvements to modboundary:
  • Consistent notation for all the cases e.g. BCxm, BCyq etc. For example, 1 - periodic, 2 - inflow-outflow, 3 - driver.
  • Same implementation for BCs in y-direction as x-direction. Currently cannot set inflow-outflow conditions for scalars in y-direction apart from specific subroutine scalSIRANE.
  • scalSIRANE, change name or remove as will not be needed if above is correctly implemented.
  • NOTE: currently overwriting by setting sv_top to svprof(ke) in modstartup.
@tomgrylls
Copy link
Contributor Author

Additional thing to check in modboundary:

Scalar boundary conditions only set to ke + 1. This should be ke+khc. This change may require variables changing including svprof that is only allocated to ke+kh?

@tomgrylls
Copy link
Contributor Author

Attention is required on the calculation of uouttot with regards to the different momentum forcings and how they are used in modboundary. This was already mentioned above but https://github.com/uDALES/u-dales/pull/70/files/858986c1bddf8ff3e2f8143f934efa8b78118eb1#r406108539 mentions a specific important example.

@tomgrylls
Copy link
Contributor Author

Note that uouttot is overwritten in a later subroutine if idriver = 2 (in subroutine iolet). This should be brought into the main loop at the start of subroutine boundary for consistency.

@samoliverowens
Copy link
Contributor

Modboundary was restructured for uDALES v2, but modinlet is unchanged since this issue was initially raised. I think it should be removed entirely.

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

No branches or pull requests

4 participants