`int_bounds_info` started as a simple beg/end integer pair but has grown into a full boundary-condition parameter struct. The name is now misleading, the internal naming is inconsistent, and the type conflates two distinct concerns. This issue tracks restructuring it for clarity.
Current state
type int_bounds_info
integer :: beg, end ! BC type codes / MPI neighbor ranks
real(wp) :: vb1, vb2, vb3 ! wall velocity at beg face (components 1,2,3)
real(wp) :: ve1, ve2, ve3 ! wall velocity at end face (components 1,2,3)
real(wp) :: pres_in, pres_out ! prescribed pressure (GRCBC)
real(wp), dimension(3) :: vel_in, vel_out ! prescribed velocity (GRCBC)
real(wp), dimension(num_fluids_max) :: alpha_rho_in, alpha_in
logical :: grcbc_in, grcbc_out, grcbc_vel_out
logical :: isothermal_in, isothermal_out
real(wp) :: Twall_in, Twall_out
end type int_bounds_info
! Declared as three flat variables:
type(int_bounds_info) :: bc_x, bc_y, bc_z
Problems:
- Misnamed —
int_bounds_info implies integer index bounds; the type now holds full BC physics.
- Inconsistent face naming —
vb/ve (wall velocity) and _in/_out (everything else) both encode the same spatial concept (beg face vs end face), just with different conventions.
- Two concerns in one type — the integer
beg/end codes (MPI ranks / BC type selectors) are unrelated to the physical face parameters.
- Flat
bc_x/bc_y/bc_z — should be bc%x, bc%y, bc%z, consistent with every other x/y/z grouping in the codebase (an unused bc_xyz_info wrapper type already exists for this purpose).
Proposed restructure
!> Physical parameters for one face of a domain boundary.
type bc_face_t
real(wp) :: pres ! prescribed pressure (GRCBC)
real(wp), dimension(3) :: vel ! prescribed velocity (GRCBC)
! Kept as individual scalars (not an array) for GPU_DECLARE compatibility:
real(wp) :: vel_wall_1 ! wall velocity, component 1
real(wp) :: vel_wall_2 ! wall velocity, component 2
real(wp) :: vel_wall_3 ! wall velocity, component 3
real(wp), dimension(num_fluids_max) :: alpha_rho ! partial densities (inflow)
real(wp), dimension(num_fluids_max) :: alpha ! volume fractions (inflow)
real(wp) :: T_wall ! wall temperature (isothermal BC)
logical :: grcbc ! GRCBC enabled
logical :: grcbc_vel ! GRCBC velocity outflow
logical :: isothermal ! isothermal wall
end type bc_face_t
!> Boundary condition info for one coordinate direction.
type bc_dir_t
integer :: beg, end
type(bc_face_t) :: beg_face
type(bc_face_t) :: end_face
end type bc_dir_t
!> All domain boundary conditions, replacing flat bc_x/bc_y/bc_z.
type bc_t
type(bc_dir_t) :: x, y, z
end type bc_t
type(bc_t) :: bc
Old → new access:
| Old |
New |
bc_x%beg |
bc%x%beg |
bc_x%vb1 |
bc%x%beg_face%vel_wall_1 |
bc_x%ve1 |
bc%x%end_face%vel_wall_1 |
bc_x%pres_in |
bc%x%beg_face%pres |
bc_x%pres_out |
bc%x%end_face%pres |
bc_x%vel_in |
bc%x%beg_face%vel |
bc_x%vel_out |
bc%x%end_face%vel |
bc_x%grcbc_in |
bc%x%beg_face%grcbc |
bc_x%grcbc_out |
bc%x%end_face%grcbc |
bc_x%grcbc_vel_out |
bc%x%end_face%grcbc_vel |
bc_x%isothermal_in |
bc%x%beg_face%isothermal |
bc_x%Twall_in |
bc%x%beg_face%T_wall |
bc_x%alpha_rho_in |
bc%x%beg_face%alpha_rho |
Scope
Files that need updating:
src/common/m_derived_types.fpp — type definitions (drop int_bounds_info, bc_xyz_info; add bc_face_t, bc_dir_t, bc_t)
src/common/m_boundary_common.fpp — all field accesses (~50 sites)
src/simulation/m_global_parameters.fpp — declarations and GPU_DECLARE macros
src/simulation/m_start_up.fpp — GPU_UPDATE macros and initialization
src/simulation/m_mpi_proxy.fpp — field names in MPI broadcast strings
src/pre_process/m_global_parameters.fpp — declarations
- Any other sites using
bc_x%, bc_y%, bc_z%
The GPU_DECLARE macros become e.g.:
$:GPU_DECLARE(create='[bc%x%beg_face%vel_wall_1, bc%x%beg_face%vel_wall_2, bc%x%beg_face%vel_wall_3, \
bc%x%end_face%vel_wall_1, ...]')
`int_bounds_info` started as a simple beg/end integer pair but has grown into a full boundary-condition parameter struct. The name is now misleading, the internal naming is inconsistent, and the type conflates two distinct concerns. This issue tracks restructuring it for clarity.
Current state
type int_bounds_info integer :: beg, end ! BC type codes / MPI neighbor ranks real(wp) :: vb1, vb2, vb3 ! wall velocity at beg face (components 1,2,3) real(wp) :: ve1, ve2, ve3 ! wall velocity at end face (components 1,2,3) real(wp) :: pres_in, pres_out ! prescribed pressure (GRCBC) real(wp), dimension(3) :: vel_in, vel_out ! prescribed velocity (GRCBC) real(wp), dimension(num_fluids_max) :: alpha_rho_in, alpha_in logical :: grcbc_in, grcbc_out, grcbc_vel_out logical :: isothermal_in, isothermal_out real(wp) :: Twall_in, Twall_out end type int_bounds_info ! Declared as three flat variables: type(int_bounds_info) :: bc_x, bc_y, bc_zProblems:
int_bounds_infoimplies integer index bounds; the type now holds full BC physics.vb/ve(wall velocity) and_in/_out(everything else) both encode the same spatial concept (beg face vs end face), just with different conventions.beg/endcodes (MPI ranks / BC type selectors) are unrelated to the physical face parameters.bc_x/bc_y/bc_z— should bebc%x,bc%y,bc%z, consistent with every other x/y/z grouping in the codebase (an unusedbc_xyz_infowrapper type already exists for this purpose).Proposed restructure
!> Physical parameters for one face of a domain boundary. type bc_face_t real(wp) :: pres ! prescribed pressure (GRCBC) real(wp), dimension(3) :: vel ! prescribed velocity (GRCBC) ! Kept as individual scalars (not an array) for GPU_DECLARE compatibility: real(wp) :: vel_wall_1 ! wall velocity, component 1 real(wp) :: vel_wall_2 ! wall velocity, component 2 real(wp) :: vel_wall_3 ! wall velocity, component 3 real(wp), dimension(num_fluids_max) :: alpha_rho ! partial densities (inflow) real(wp), dimension(num_fluids_max) :: alpha ! volume fractions (inflow) real(wp) :: T_wall ! wall temperature (isothermal BC) logical :: grcbc ! GRCBC enabled logical :: grcbc_vel ! GRCBC velocity outflow logical :: isothermal ! isothermal wall end type bc_face_t !> Boundary condition info for one coordinate direction. type bc_dir_t integer :: beg, end type(bc_face_t) :: beg_face type(bc_face_t) :: end_face end type bc_dir_t !> All domain boundary conditions, replacing flat bc_x/bc_y/bc_z. type bc_t type(bc_dir_t) :: x, y, z end type bc_t type(bc_t) :: bcOld → new access:
bc_x%begbc%x%begbc_x%vb1bc%x%beg_face%vel_wall_1bc_x%ve1bc%x%end_face%vel_wall_1bc_x%pres_inbc%x%beg_face%presbc_x%pres_outbc%x%end_face%presbc_x%vel_inbc%x%beg_face%velbc_x%vel_outbc%x%end_face%velbc_x%grcbc_inbc%x%beg_face%grcbcbc_x%grcbc_outbc%x%end_face%grcbcbc_x%grcbc_vel_outbc%x%end_face%grcbc_velbc_x%isothermal_inbc%x%beg_face%isothermalbc_x%Twall_inbc%x%beg_face%T_wallbc_x%alpha_rho_inbc%x%beg_face%alpha_rhoScope
Files that need updating:
src/common/m_derived_types.fpp— type definitions (dropint_bounds_info,bc_xyz_info; addbc_face_t,bc_dir_t,bc_t)src/common/m_boundary_common.fpp— all field accesses (~50 sites)src/simulation/m_global_parameters.fpp— declarations andGPU_DECLAREmacrossrc/simulation/m_start_up.fpp—GPU_UPDATEmacros and initializationsrc/simulation/m_mpi_proxy.fpp— field names in MPI broadcast stringssrc/pre_process/m_global_parameters.fpp— declarationsbc_x%,bc_y%,bc_z%The
GPU_DECLAREmacros become e.g.: