You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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:
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.
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:
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?linoutflow
andlper2inout
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.ubulk
anduouttot
(see Check the use of ubulk and uouttot #54 ). See ?.BCxm
,BCyq
etc. For example, 1 - periodic, 2 - inflow-outflow, 3 - driver.sv_top
tosvprof(ke)
in modstartup.The text was updated successfully, but these errors were encountered: