Refactor `m_riemann_solvers` Module (Non-Solver Subroutines) #908

Malmahrouqi3 · 2025-06-29T23:03:22Z

User description

Description

Reduced PR from (#855),

Essentially, I reduced non-math-critical subroutines slightly. In addition, I added s_compute_wave_speed as a comprehensive subroutine to tackle its calcs for all Riemann Solvers (HLL, HLLC, HLLD).

PR Type

Enhancement

Description

Refactor wave speed calculations into centralized subroutine
Consolidate Riemann solver buffer population logic
Clean up code formatting and variable declarations
Add debug validation for wave speed calculations

Diagram Walkthrough

flowchart LR
  A["Duplicate wave speed code"] --> B["s_compute_wave_speed subroutine"]
  C["Separate buffer population"] --> D["Unified buffer handling"]
  E["Scattered formatting"] --> F["Consistent code style"]
  B --> G["Centralized wave speed logic"]
  D --> G
  F --> G

File Walkthrough

Relevant files

Enhancement

m_variables_conversion.fpp `Add centralized wave speed computation subroutine` src/common/m_variables_conversion.fpp Add new `s_compute_wave_speed` subroutine for centralized wave speed calculations Include comprehensive wave speed computation for all Riemann solvers (HLL, HLLC, HLLD) Add debug validation checks for wave speed consistency Export the new subroutine in module interface	+112/-0
m_riemann_solvers.fpp `Refactor Riemann solver implementation and buffer handling` src/simulation/m_riemann_solvers.fpp Replace duplicate wave speed calculation code with calls to `s_compute_wave_speed` Consolidate buffer population logic across x/y/z directions Update variable declarations from `INOUT` to `inout` for consistency Simplify flux reshaping logic by combining similar operations Add pointer declarations for unified buffer handling	+181/-701

qodo-merge-pro · 2025-06-29T23:03:56Z

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review Possible Issue The new s_compute_wave_speed subroutine has complex conditional logic with multiple physics models (elasticity, mhd, hypoelasticity, hyperelasticity) but lacks comprehensive validation. The wave speed calculations involve intricate mathematical formulations that could introduce numerical errors or incorrect physics handling. subroutine s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, & c_L, c_R, c_avg, c_fast_L, c_fast_R, G_L, G_R, & tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, idx, idx_tau) ! Computes the wave speeds for the Riemann solver #ifdef _CRAYFTN !DIR$ INLINEALWAYS s_compute_wave_speed #else !$acc routine seq #endif ! Input parameters integer, intent(in) :: wave_speeds integer, intent(in) :: idx, idx_tau real(wp), intent(in) :: rho_L, rho_R real(wp), dimension(:), intent(in) :: vel_L, vel_R, tau_e_L, tau_e_R real(wp), intent(in) :: pres_L, pres_R, c_L, c_R real(wp), intent(in) :: gamma_L, gamma_R, pi_inf_L, pi_inf_R real(wp), intent(in) :: rho_avg, c_avg real(wp), intent(in) :: c_fast_L, c_fast_R real(wp), intent(in) :: G_L, G_R ! Local variables real(wp) :: pres_SL, pres_SR, Ms_L, Ms_R ! Output parameters real(wp), intent(out) :: s_L, s_R, s_S, s_M, s_P if (wave_speeds == 1) then if (elasticity) then s_L = min(vel_L(idx) - sqrt(c_Lc_L + & (((4_wpG_L)/3_wp) + tau_e_L(idx_tau))/rho_L), vel_R(idx) - sqrt(c_Rc_R + & (((4_wpG_R)/3_wp) + tau_e_R(idx_tau))/rho_R)) s_R = max(vel_R(idx) + sqrt(c_Rc_R + & (((4_wpG_R)/3_wp) + tau_e_R(idx_tau))/rho_R), vel_L(idx) + sqrt(c_Lc_L + & (((4_wpG_L)/3_wp) + tau_e_L(idx_tau))/rho_L)) s_S = (pres_R - tau_e_R(idx_tau) - pres_L + & tau_e_L(idx_tau) + rho_Lvel_L(idx)(s_L - vel_L(idx)) - & rho_Rvel_R(idx)(s_R - vel_R(idx)))/(rho_L(s_L - vel_L(idx)) - & rho_R(s_R - vel_R(idx))) else if (mhd) then s_L = min(vel_L(idx) - c_fast_L, vel_R(idx) - c_fast_R) s_R = max(vel_R(idx) + c_fast_R, vel_L(idx) + c_fast_L) s_S = (pres_R - pres_L + rho_Lvel_L(idx) & (s_L - vel_L(idx)) - rho_Rvel_R(idx)(s_R - vel_R(idx))) & /(rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))) else if (hypoelasticity) then s_L = min(vel_L(idx) - sqrt(c_Lc_L + (((4._wpG_L)/3._wp) + & tau_e_L(idx_tau))/rho_L) & , vel_R(idx) - sqrt(c_Rc_R + (((4._wpG_R)/3._wp) + & tau_e_R(idx_tau))/rho_R)) s_R = max(vel_R(idx) + sqrt(c_Rc_R + (((4._wpG_R)/3._wp) + & tau_e_R(idx_tau))/rho_R) & , vel_L(idx) + sqrt(c_Lc_L + (((4._wpG_L)/3._wp) + & tau_e_L(idx_tau))/rho_L)) s_S = (pres_R - pres_L + rho_Lvel_L(idx) & (s_L - vel_L(idx)) - rho_Rvel_R(idx)(s_R - vel_R(idx))) & /(rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))) else if (hyperelasticity) then s_L = min(vel_L(idx) - sqrt(c_Lc_L + (4._wpG_L/3._wp)/rho_L) & , vel_R(idx) - sqrt(c_Rc_R + (4._wpG_R/3._wp)/rho_R)) s_R = max(vel_R(idx) + sqrt(c_Rc_R + (4._wpG_R/3._wp)/rho_R) & , vel_L(idx) + sqrt(c_Lc_L + (4._wpG_L/3._wp)/rho_L)) s_S = (pres_R - pres_L + rho_Lvel_L(idx) & (s_L - vel_L(idx)) - rho_Rvel_R(idx)(s_R - vel_R(idx))) & /(rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))) else s_L = min(vel_L(idx) - c_L, vel_R(idx) - c_R) s_R = max(vel_R(idx) + c_R, vel_L(idx) + c_L) s_S = (pres_R - pres_L + rho_Lvel_L(idx) & (s_L - vel_L(idx)) - rho_Rvel_R(idx)(s_R - vel_R(idx))) & /(rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))) end if else if (wave_speeds == 2) then pres_SL = 5e-1_wp(pres_L + pres_R + rho_avgc_avg(vel_L(idx) - vel_R(idx))) pres_SR = pres_SL Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L)) & (pres_SL/pres_L - 1._wp)pres_L/ & ((pres_L + pi_inf_L/(1._wp + gamma_L))))) Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R)) & (pres_SR/pres_R - 1._wp)pres_R/ & ((pres_R + pi_inf_R/(1._wp + gamma_R))))) s_L = vel_L(idx) - c_LMs_L s_R = vel_R(idx) + c_RMs_R s_S = 5e-1_wp((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avgc_avg)) end if ! ! follows Einfeldt et al. ! s_M/P = min/max(0.,s_L/R) s_M = min(0._wp, s_L) s_P = max(0._wp, s_R) #ifdef DEBUG ! Check for potential issues in wave speed calculation if (s_R <= s_L) then print , 'WARNING: Wave speed issue detected in s_compute_wave_speed' print , 'Left wave speed >= Right wave speed:', s_L, s_R print , 'Input velocities :', vel_L(idx), vel_R(idx) print , 'Sound speeds:', c_L, c_R print , 'Densities:', rho_L, rho_R print , 'Pressures:', pres_L, pres_R print , 'Wave speeds method:', wave_speeds if (elasticity .or. hypoelasticity .or. hyperelasticity) then print , 'Shear moduli:', G_L, G_R end if call s_mpi_abort('Error: Invalid wave speeds in s_compute_wave_speed') end if #endif end subroutine s_compute_wave_speed #endif Code Duplication* After the refactoring, there are still redundant wave speed calculations present. Line 690 shows s_M and s_P being recalculated immediately after calling s_compute_wave_speed, which already computes these values. This suggests incomplete refactoring and potential inconsistencies. call s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, & c_L, c_R, c_avg, c_fast%L, c_fast%R, G_L, G_R, & tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1)) s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) Logic Error In the buffer population logic, there are undefined variables like 'j' being used in conditional blocks without proper declaration or loop context. This could lead to compilation errors or undefined behavior during runtime. dqL_prim_dx_vf(i)%sf(j, -1, l) = dqR_prim_dx_vf(i)%sf(j, 0, l) dqL_prim_dy_vf(i)%sf(j, -1, l) = dqR_prim_dy_vf(i)%sf(j, 0, l) if (p > 0) then dqL_prim_dz_vf(i)%sf(j, -1, l) = dqR_prim_dz_vf(i)%sf(j, 0, l) end if else dqL_prim_dx_vf(i)%sf(j, k, -1) = dqR_prim_dx_vf(i)%sf(j, k, 0) dqL_prim_dy_vf(i)%sf(j, k, -1) = dqR_prim_dy_vf(i)%sf(j, k, 0) dqL_prim_dz_vf(i)%sf(j, k, -1) = dqR_prim_dz_vf(i)%sf(j, k, 0) end if

Copilot

Pull Request Overview

This PR refactors the m_riemann_solvers module by extracting all inline wave‐speed logic into a new s_compute_wave_speed subroutine, and cleans up buffer initializations with pointers and target attributes.

Adds s_compute_wave_speed (in m_variables_conversion) to centralize all HLL/HLLC/HLLD wave‐speed formulas.
Updates m_riemann_solvers.fpp to call s_compute_wave_speed instead of duplicating logic, and refactors boundary‐buffer routines using pointer/target.
Adjusts variable declarations (intent, allocatable, pointer, new bc_beg, bc_end, end_val) for directional BC handling.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/simulation/m_riemann_solvers.fpp	Replaced duplicated wave‐speed blocks with calls to `s_compute_wave_speed`; refactored Riemann buffer loops with pointers/targets and unified BC handling
src/common/m_variables_conversion.fpp	Exported and implemented new `s_compute_wave_speed` subroutine under `#ifndef MFC_PRE_PROCESS`

Comments suppressed due to low confidence (2)

src/common/m_variables_conversion.fpp:1714

There’s no !> docstring for s_compute_wave_speed. Add a header explaining the purpose, inputs, and outputs, so future readers can quickly understand the routine.

    subroutine s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, &

src/common/m_variables_conversion.fpp:1714

The newly introduced s_compute_wave_speed contains complex branching for multiple wave‐speed methods but no dedicated unit tests. Consider adding focused tests covering both wave_speeds==1 and wave_speeds==2 paths.

    subroutine s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, &

src/simulation/m_riemann_solvers.fpp

src/common/m_variables_conversion.fpp

qodo-merge-pro · 2025-06-29T23:04:54Z

PR Code Suggestions ✨

Latest suggestions up to dd158d0

Category	Suggestion	Impact
Possible issue	Fix wave speed validation condition The condition `s_R <= s_L` should be `s_R < s_L` to properly detect invalid wave speeds. Wave speeds can be equal in degenerate cases without being invalid. The current condition may trigger false positives when `s_R = s_L`. src/common/m_variables_conversion.fpp [1809-1821] -if (s_R <= s_L) then +if (s_R < s_L) then print , 'WARNING: Wave speed issue detected in s_compute_wave_speed' - print , 'Left wave speed >= Right wave speed:', s_L, s_R + print , 'Left wave speed > Right wave speed:', s_L, s_R print , 'Input velocities :', vel_L(idx), vel_R(idx) print , 'Sound speeds:', c_L, c_R print , 'Densities:', rho_L, rho_R print , 'Pressures:', pres_L, pres_R print , 'Wave speeds method:', wave_speeds if (elasticity .or. hypoelasticity .or. hyperelasticity) then print *, 'Shear moduli:', G_L, G_R end if call s_mpi_abort('Error: Invalid wave speeds in s_compute_wave_speed') end if Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that the check `s_R <= s_L` could cause a false positive abort when `s_R == s_L`, which can be a valid physical state, thus improving the robustness of the debug validation.	Low
Possible issue	Prevent division by zero error Add validation to prevent division by zero in the `s_S` calculation. The denominator `rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))` could become zero in degenerate cases, leading to numerical instability.** src/common/m_variables_conversion.fpp [1743-1754] if (wave_speeds == 1) then if (elasticity) then s_L = min(vel_L(idx) - sqrt(c_Lc_L + & (((4_wpG_L)/3_wp) + tau_e_L(idx_tau))/rho_L), vel_R(idx) - sqrt(c_Rc_R + & (((4_wpG_R)/3_wp) + tau_e_R(idx_tau))/rho_R)) s_R = max(vel_R(idx) + sqrt(c_Rc_R + & (((4_wpG_R)/3_wp) + tau_e_R(idx_tau))/rho_R), vel_L(idx) + sqrt(c_Lc_L + & (((4_wpG_L)/3_wp) + tau_e_L(idx_tau))/rho_L)) - s_S = (pres_R - tau_e_R(idx_tau) - pres_L + & - tau_e_L(idx_tau) + rho_Lvel_L(idx)(s_L - vel_L(idx)) - & - rho_Rvel_R(idx)(s_R - vel_R(idx)))/(rho_L(s_L - vel_L(idx)) - & - rho_R(s_R - vel_R(idx))) + + real(wp) :: denom + denom = rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx)) + if (abs(denom) < epsilon(1.0_wp)) then + s_S = 0.5_wp * (vel_L(idx) + vel_R(idx)) + else + s_S = (pres_R - tau_e_R(idx_tau) - pres_L + & + tau_e_L(idx_tau) + rho_Lvel_L(idx)(s_L - vel_L(idx)) - & + rho_Rvel_R(idx)(s_R - vel_R(idx)))/denom + end if Suggestion importance[1-10]: 8 __ Why: This is a valid and important suggestion to prevent a potential division-by-zero runtime error, which could cause a crash, by adding a check on the denominator.	Medium
Possible issue	Add input validation for norm_dir Add validation to ensure `norm_dir` is within valid range (1-3) before using it in the conditional logic. Invalid values could cause undefined behavior or incorrect pointer assignments. src/simulation/m_riemann_solvers.fpp [3177-3204] +if (norm_dir < 1 .or. norm_dir > 3) then + call s_mpi_abort('Error: Invalid norm_dir value in s_populate_riemann_states_variables_buffers') +end if + if (norm_dir == 1) then is1 = ix; is2 = iy; is3 = iz dir_idx = (/1, 2, 3/); dir_flg = (/1._wp, 0._wp, 0._wp/) bc_beg = bc_x%beg; bc_end = bc_x%end end_val = m qL_prim_rs_vf => qL_prim_rsx_vf qR_prim_rs_vf => qR_prim_rsx_vf dqL_prim_d_vf => dqL_prim_dx_vf dqR_prim_d_vf => dqR_prim_dx_vf else if (norm_dir == 2) then is1 = iy; is2 = ix; is3 = iz dir_idx = (/2, 1, 3/); dir_flg = (/0._wp, 1._wp, 0._wp/) bc_beg = bc_y%beg; bc_end = bc_y%end end_val = n qL_prim_rs_vf => qL_prim_rsy_vf qR_prim_rs_vf => qR_prim_rsy_vf dqL_prim_d_vf => dqL_prim_dy_vf dqR_prim_d_vf => dqR_prim_dy_vf else is1 = iz; is2 = iy; is3 = ix dir_idx = (/3, 1, 2/); dir_flg = (/0._wp, 0._wp, 1._wp/) bc_beg = bc_z%beg; bc_end = bc_z%end end_val = p qL_prim_rs_vf => qL_prim_rsz_vf qR_prim_rs_vf => qR_prim_rsz_vf dqL_prim_d_vf => dqL_prim_dz_vf dqR_prim_d_vf => dqR_prim_dz_vf end if Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that an invalid `norm_dir` would fall into the `else` block, causing incorrect pointer assignments; adding a check improves code robustness.	Medium
Update

Previous suggestions

✅ Suggestions up to commit b684a4e

Category	Suggestion	Impact
Possible issue	Fix wave speed validation condition The debug check uses `s_R <= s_L` which will trigger for valid cases where wave speeds are equal. This condition should be `s_R < s_L` to only catch truly invalid configurations where the right wave speed is strictly less than the left wave speed. src/common/m_variables_conversion.fpp [1809-1822] -if (s_R <= s_L) then +if (s_R < s_L) then print , 'WARNING: Wave speed issue detected in s_compute_wave_speed' - print , 'Left wave speed >= Right wave speed:', s_L, s_R + print , 'Left wave speed > Right wave speed:', s_L, s_R print , 'Input velocities :', vel_L(idx), vel_R(idx) print , 'Sound speeds:', c_L, c_R print , 'Densities:', rho_L, rho_R print , 'Pressures:', pres_L, pres_R print , 'Wave speeds method:', wave_speeds if (elasticity .or. hypoelasticity .or. hyperelasticity) then print *, 'Shear moduli:', G_L, G_R end if call s_mpi_abort('Error: Invalid wave speeds in s_compute_wave_speed') end if Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that the debug check `s_R <= s_L` is too strict and would cause an abort in valid cases where `s_R == s_L`, improving the robustness of the validation logic.	Medium
General	✅ ~~Remove redundant wave speed calculations~~ Suggestion Impact: The commit removed multiple instances of redundant s_M and s_P calculations throughout the code, exactly as suggested. The lines "s_M = min(0._wp, s_L); s_P = max(0._wp, s_R)" were removed from several locations. code diff: - - s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) xi_M = (5.e-1_wp + sign(5.e-1_wp, s_L)) & + (5.e-1_wp - sign(5.e-1_wp, s_L)) & @@ -1445,10 +1443,6 @@ tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1)) - ! follows Einfeldt et al. - ! s_M/P = min/max(0.,s_L/R) - s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) - ! goes with q_star_L/R = xi_L/R * (variable) ! xi_L/R = ( ( s_L/R - u_L/R )/(s_L/R - s_star) ) xi_L = (s_L - vel_L(idx1))/(s_L - s_S) @@ -1717,10 +1711,6 @@ c_L, c_R, c_avg, c_fast%L, c_fast%R, G_L, G_R, & tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1)) - - ! follows Einfeldt et al. - ! s_M/P = min/max(0.,s_L/R) - s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) ! goes with q_star_L/R = xi_L/R * (variable) ! xi_L/R = ( ( s_L/R - u_L/R )/(s_L/R - s_star) ) @@ -2120,10 +2110,6 @@ tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1)) - ! follows Einfeldt et al. - ! s_M/P = min/max(0.,s_L/R) - s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) - ! goes with q_star_L/R = xi_L/R * (variable) ! xi_L/R = ( ( s_L/R - u_L/R )/(s_L/R - s_star) ) xi_L = (s_L - vel_L(dir_idx(1)))/(s_L - s_S) @@ -2562,10 +2548,6 @@ tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1)) - ! follows Einfeldt et al. - ! s_M/P = min/max(0.,s_L/R) - s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) This line duplicates the wave speed calculation that is already performed inside `s_compute_wave_speed`. The `s_M` and `s_P` values are already computed and returned by the subroutine, making this redundant calculation unnecessary. src/simulation/m_riemann_solvers.fpp [690] -s_M = min(0._wp, s_L); s_P = max(0._wp, s_R) +! s_M and s_P are already computed in s_compute_wave_speed Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that the calculation of `s_M` and `s_P` is redundant, as these values are now computed and returned by the new `s_compute_wave_speed` subroutine.	Low

Malmahrouqi3 · 2025-06-29T23:12:12Z

Code Duplication
After the refactoring, there are still redundant wave speed calculations present. Line 690 shows s_M and s_P being recalculated immediately after calling s_compute_wave_speed, which already computes these values. This suggests incomplete refactoring and potential inconsistencies.

Good catch, I forgot about it honestly when replacing wave speed calcs with the subroutine call. Thnx.

codecov · 2025-06-30T01:22:37Z

Codecov Report

❌ Patch coverage is 39.34426% with 37 lines in your changes missing coverage. Please review.
✅ Project coverage is 40.92%. Comparing base (e966781) to head (89064af).

Files with missing lines	Patch %	Lines
src/common/m_variables_conversion.fpp	35.71%	34 Missing and 2 partials ⚠️
src/simulation/m_riemann_solvers.fpp	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #908   +/-   ##
=======================================
  Coverage   40.91%   40.92%           
=======================================
  Files          70       70           
  Lines       20270    20251   -19     
  Branches     2520     2514    -6     
=======================================
- Hits         8293     8287    -6     
+ Misses      10439    10430    -9     
+ Partials     1538     1534    -4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sbryngelson · 2025-06-30T02:22:44Z

be sure to run tests on frontier and phoenix (amd and nvidia gpu) before pushing. helps you debug faster and saves the runners to do other things.

Malmahrouqi3 · 2025-06-30T02:29:39Z

Roger that

src/common/m_variables_conversion.fpp

sbryngelson · 2025-06-30T03:03:09Z

src/common/m_variables_conversion.fpp

 #endif

+#ifndef MFC_PRE_PROCESS
+    subroutine s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, &


surely some of these arguments should be optional since not every riemann solver uses them all?

yup yup, not all of them will be used in every scenario. I will look into a way to reduce that as the subroutine call looks the same in every solver yet not neat-looking

call s_compute_wave_speed(wave_speeds, vel_L, vel_R, pres_L, pres_R, rho_L, rho_R, rho_avg, & c_L, c_R, c_avg, c_fast%L, c_fast%R, G_L, G_R, & tau_e_L, tau_e_R, gamma_L, gamma_R, pi_inf_L, pi_inf_R, & s_L, s_R, s_S, s_M, s_P, dir_idx(1), dir_idx_tau(1))

sbryngelson · 2025-06-30T13:48:53Z

Code Duplication
After the refactoring, there are still redundant wave speed calculations present. Line 690 shows s_M and s_P being recalculated immediately after calling s_compute_wave_speed, which already computes these values. This suggests incomplete refactoring and potential inconsistencies.

Good catch, I forgot about it honestly when replacing wave speed calcs with the subroutine call. Thnx.

@Malmahrouqi3
You don't have to reply to every Copilot or Qodo PR comment. They're just supposed to be handy to look at. I look too, but ignore most of them. But sometimes a useful comment or suggestion pops up.

Malmahrouqi3 · 2025-07-01T03:25:28Z

Not frankly sure what is happening. I tried interactive where all tests passed vs. slurm where all tests failed for phoenix gpu. No specific error messages e.g. tolerance issue or such, yet prolly due to the lint issue. I will fix that and re-run the slurm job.

sbryngelson · 2025-07-01T03:37:33Z

The error is only on GPU cases and is because you did something with OpenACC incorrectly:

FATAL ERROR: data in PRESENT clause was not found on device 1: name=c_fast host:0x3d77820
 file:/storage/scratch1/6/sbryngelson3/mfc-runners/actions-runner-03/_work/MFC/MFC/src/simulation/m_riemann_solvers.fpp s_hllc_riemann_solver line:2287

sbryngelson · 2025-07-01T03:39:46Z

src/simulation/m_riemann_solvers.fpp


        integer :: i, j, k, l, q !< Generic loop iterators
        integer :: idx1, idxi
+        type(riemann_states) :: c_fast, vel


i don't think this is right

I added this initially like a while back as it gave me errors and refused to complete the build. More likely the reason tho, I will look into this.

Malmahrouqi3 · 2025-09-02T00:11:37Z

Self Hosted (gpu, frontier) failed above but everything passed when I tried manually running all tests there.

qodo-merge-pro · 2025-09-02T00:12:14Z

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review Possible Issue The new debug block aborts execution when s_R <= s_L. In degenerate or contact cases, equality can occur without being invalid. Verify whether strict inequality is intended; otherwise consider relaxing the check or guarding against benign equalities to avoid false aborts. ! Check for potential issues in wave speed calculation if (s_R <= s_L) then print , 'WARNING: Wave speed issue detected in s_compute_wave_speed' print , 'Left wave speed >= Right wave speed:', s_L, s_R print , 'Input velocities :', vel_L(idx), vel_R(idx) print , 'Sound speeds:', c_L, c_R print , 'Densities:', rho_L, rho_R print , 'Pressures:', pres_L, pres_R print , 'Wave speeds method:', wave_speeds if (elasticity .or. hypoelasticity .or. hyperelasticity) then print , 'Shear moduli:', G_L, G_R end if call s_mpi_abort('Error: Invalid wave speeds in s_compute_wave_speed') end if Indexing Risk In the unified buffer population, some branches write dqL/dqR using j and k indices that are not declared within the local loop scope or may not align with the nested loops, risking out-of-bounds or wrong indexing when norm_dir switches. Review the use of j/k/l across norm_dir branches and ensure loop indices match array subscripts. $:GPU_PARALLEL_LOOP(collapse=3) do i = momxb, momxe do l = isz%beg, isz%end do k = isy%beg, isy%end if (norm_dir == 1) then dqL_prim_dx_vf(i)%sf(-1, k, l) = dqR_prim_dx_vf(i)%sf(0, k, l) if (n > 0) then dqL_prim_dy_vf(i)%sf(-1, k, l) = dqR_prim_dy_vf(i)%sf(0, k, l) if (p > 0) then dqL_prim_dz_vf(i)%sf(-1, k, l) = dqR_prim_dz_vf(i)%sf(0, k, l) end if end if else if (norm_dir == 2) then dqL_prim_dx_vf(i)%sf(j, -1, l) = dqR_prim_dx_vf(i)%sf(j, 0, l) dqL_prim_dy_vf(i)%sf(j, -1, l) = dqR_prim_dy_vf(i)%sf(j, 0, l) if (p > 0) then dqL_prim_dz_vf(i)%sf(j, -1, l) = dqR_prim_dz_vf(i)%sf(j, 0, l) end if else dqL_prim_dx_vf(i)%sf(j, k, -1) = dqR_prim_dx_vf(i)%sf(j, k, 0) dqL_prim_dy_vf(i)%sf(j, k, -1) = dqR_prim_dy_vf(i)%sf(j, k, 0) dqL_prim_dz_vf(i)%sf(j, k, -1) = dqR_prim_dz_vf(i)%sf(j, k, 0) end if end do end do end do end if end if if (bc_end == BC_RIEMANN_EXTRAP) then ! Riemann state extrap. BC at end $:GPU_PARALLEL_LOOP(collapse=3) do i = 1, sys_size do l = is3%beg, is3%end do k = is2%beg, is2%end qR_prim_rs_vf(end_val + 1, k, l, i) = qL_prim_rs_vf(end_val, k, l, i) end do end do end do if (viscous) then $:GPU_PARALLEL_LOOP(collapse=3) do i = momxb, momxe do l = isz%beg, isz%end do k = isy%beg, isy%end if (norm_dir == 1) then dqR_prim_dx_vf(i)%sf(end_val + 1, k, l) = dqL_prim_dx_vf(i)%sf(end_val, k, l) if (n > 0) then dqR_prim_dy_vf(i)%sf(end_val + 1, k, l) = dqL_prim_dy_vf(i)%sf(end_val, k, l) if (p > 0) then dqR_prim_dz_vf(i)%sf(end_val + 1, k, l) = dqL_prim_dz_vf(i)%sf(end_val, k, l) end if end if else if (norm_dir == 2) then dqR_prim_dx_vf(i)%sf(j, end_val + 1, l) = dqL_prim_dx_vf(i)%sf(j, end_val, l) dqR_prim_dy_vf(i)%sf(j, end_val + 1, l) = dqL_prim_dy_vf(i)%sf(j, end_val, l) if (p > 0) then dqR_prim_dz_vf(i)%sf(j, end_val + 1, l) = dqL_prim_dz_vf(i)%sf(j, end_val, l) end if else dqR_prim_dx_vf(i)%sf(j, k, end_val + 1) = dqL_prim_dx_vf(i)%sf(j, k, end_val) dqR_prim_dy_vf(i)%sf(j, k, end_val + 1) = dqL_prim_dy_vf(i)%sf(j, k, end_val) dqR_prim_dz_vf(i)%sf(j, k, end_val + 1) = dqL_prim_dz_vf(i)%sf(j, k, end_val) end if end do end do end do API Consistency Several dummy arguments had intent changed from INOUT to inout and some were made target/pointer. Ensure callers and interfaces are updated accordingly and that pointer aliasing does not introduce unintended side effects or performance regressions on GPU paths. dqR_prim_dy_vf, & dqR_prim_dz_vf, & qR_prim_vf, & q_prim_vf, & flux_vf, flux_src_vf, & flux_gsrc_vf, & norm_dir, ix, iy, iz) real(wp), dimension(idwbuff(1)%beg:, idwbuff(2)%beg:, idwbuff(3)%beg:, 1:), intent(inout) :: qL_prim_rsx_vf, qL_prim_rsy_vf, qL_prim_rsz_vf, qR_prim_rsx_vf, qR_prim_rsy_vf, qR_prim_rsz_vf type(scalar_field), dimension(sys_size), intent(IN) :: q_prim_vf type(scalar_field), allocatable, dimension(:), intent(inout) :: qL_prim_vf, qR_prim_vf type(scalar_field), & allocatable, dimension(:), & intent(inout) :: dqL_prim_dx_vf, dqR_prim_dx_vf, & dqL_prim_dy_vf, dqR_prim_dy_vf, & dqL_prim_dz_vf, dqR_prim_dz_vf type(scalar_field), & dimension(sys_size), & intent(inout) :: flux_vf, flux_src_vf, flux_gsrc_vf

qodo-merge-pro · 2025-09-02T00:15:10Z

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Fix unified buffer indexing The new unified buffer population logic in s_initialize_riemann_solver uses undefined/mismatched loop indices (e.g., references to j without a loop) and mixes isy/isz with direction-mapped is2/is3, which will misindex for norm_dir=2/3 and likely fail on GPU. Rework these sections to iterate consistently over is1/is2/is3 for each norm_dir and include the missing j loops, or revert to clear per-direction loops to ensure correct dq and qL/qR buffer updates across all directions.* Examples: src/simulation/m_riemann_solvers.fpp [3184-3211] if (viscous) then $:GPU_PARALLEL_LOOP(collapse=3) do i = momxb, momxe do l = isz%beg, isz%end do k = isy%beg, isy%end if (norm_dir == 1) then dqL_prim_dx_vf(i)%sf(-1, k, l) = dqR_prim_dx_vf(i)%sf(0, k, l) if (n > 0) then dqL_prim_dy_vf(i)%sf(-1, k, l) = dqR_prim_dy_vf(i)%sf(0, k, l) if (p > 0) then ... (clipped 18 lines) src/simulation/m_riemann_solvers.fpp [3223-3250] if (viscous) then $:GPU_PARALLEL_LOOP(collapse=3) do i = momxb, momxe do l = isz%beg, isz%end do k = isy%beg, isy%end if (norm_dir == 1) then dqR_prim_dx_vf(i)%sf(end_val + 1, k, l) = dqL_prim_dx_vf(i)%sf(end_val, k, l) if (n > 0) then dqR_prim_dy_vf(i)%sf(end_val + 1, k, l) = dqL_prim_dy_vf(i)%sf(end_val, k, l) if (p > 0) then ... (clipped 18 lines) Solution Walkthrough: Before: subroutine s_initialize_riemann_solver(...) ... if (viscous) then do i = momxb, momxe do l = isz%beg, isz%end do k = isy%beg, isy%end if (norm_dir == 1) then dqL_prim_dx_vf(i)%sf(-1, k, l) = ... else if (norm_dir == 2) then ! 'j' is used here but not defined in any loop dqL_prim_dx_vf(i)%sf(j, -1, l) = ... else ! 'j' is used here but not defined in any loop dqL_prim_dx_vf(i)%sf(j, k, -1) = ... end if end do end do end do end if ... end subroutine After: subroutine s_initialize_riemann_solver(...) ... if (viscous) then do i = momxb, momxe do l = is3%beg, is3%end do k = is2%beg, is2%end do j = is1%beg, is1%end if (norm_dir == 1) then dqL_prim_dx_vf(i)%sf(-1, k, l) = ... else if (norm_dir == 2) then dqL_prim_dx_vf(i)%sf(k, -1, l) = ... else dqL_prim_dx_vf(i)%sf(l, k, -1) = ... end if end do end do end do end do end if ... end subroutine Suggestion importance[1-10]: 10 __ Why: The suggestion correctly identifies critical bugs in the refactored buffer population logic, including use of uninitialized loop variables and incorrect indexing, which would lead to incorrect behavior and crashes, especially on GPUs.	High
Possible issue	Prevent division by zero in denominator The denominator `rho_L``(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx))` could potentially be zero or very small, leading to division by zero or numerical instability. Add a check to prevent this.** src/common/m_variables_conversion.fpp [1766-1769] -s_S = (pres_R - tau_e_R(idx_tau) - pres_L + & - tau_e_L(idx_tau) + rho_Lvel_L(idx)(s_L - vel_L(idx)) - & - rho_Rvel_R(idx)(s_R - vel_R(idx)))/(rho_L(s_L - vel_L(idx)) - & - rho_R(s_R - vel_R(idx))) +real(wp) :: denominator +denominator = rho_L(s_L - vel_L(idx)) - rho_R(s_R - vel_R(idx)) +if (abs(denominator) < 1.0e-12_wp) then + s_S = 0.5_wp * (vel_L(idx) + vel_R(idx)) +else + s_S = (pres_R - tau_e_R(idx_tau) - pres_L + & + tau_e_L(idx_tau) + rho_Lvel_L(idx)(s_L - vel_L(idx)) - & + rho_Rvel_R(idx)(s_R - vel_R(idx))) / denominator +end if Suggestion importance[1-10]: 8 __ Why: This is a valid and important suggestion to prevent potential division-by-zero errors when calculating `s_S`, which could lead to runtime crashes or numerical instability. The proposed fix is a standard and robust way to handle this.	Medium
Possible issue	Fix inconsistent wave speed validation condition The debug check uses `s_R <= s_L` but the error message says "Left wave speed >= Right wave speed". The condition should be `s_L >= s_R` to match the error message, as physically the right wave speed should be greater than the left wave speed. src/common/m_variables_conversion.fpp [1824-1836] -if (s_R <= s_L) then +if (s_L >= s_R) then print , 'WARNING: Wave speed issue detected in s_compute_wave_speed' print , 'Left wave speed >= Right wave speed:', s_L, s_R ... call s_mpi_abort('Error: Invalid wave speeds in s_compute_wave_speed') end if Suggestion importance[1-10]: 7 __ Why: The suggestion correctly points out that the logical condition `s_R <= s_L` is equivalent to the message "Left wave speed >= Right wave speed", so no change is needed. The suggestion is correct that they should match, but fails to see that they already do.	Medium
More

Malmahrouqi3 · 2025-09-02T16:02:21Z

Self Hosted (gpu, frontier)
slurmstepd: error: *** JOB 3713895 ON frontier10491 CANCELLED AT 2025-09-02T04:47:31 DUE TO TIME LIMIT ***

Malmahrouqi3 · 2025-09-07T04:21:40Z

needs to be re-triggered whenever convenient, all tests passed in my fork https://github.com/Malmahrouqi3/MFC-mo2/actions/runs/17522275514
For self-hosted ones, they passed above.

sbryngelson · 2025-09-12T16:25:31Z

/improve

src/common/m_variables_conversion.fpp

sbryngelson · 2025-09-13T15:11:41Z

This code seems to keep failing because it is too slow on the benchmark cases (I reran them a few times)

Malmahrouqi3 · 2025-09-13T15:46:02Z

This code seems to keep failing because it is too slow on the benchmark cases (I reran them a few times)

That's true, it essentially creates a subroutine for the wave speed along with using pointers and few other things. I will see if I can forgo all changes except for the wave speed subroutine.

Copilot

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

Copilot · 2025-09-17T03:35:04Z

src/common/m_variables_conversion.fpp

+            pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))
+            pres_SR = pres_SL
+            Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &
+                                   (pres_SL/pres_L - 1._wp)*pres_L/ &
+                                   ((pres_L + pi_inf_L/(1._wp + gamma_L)))))
+            Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &
+                                   (pres_SR/pres_R - 1._wp)*pres_R/ &
+                                   ((pres_R + pi_inf_R/(1._wp + gamma_R)))))
+            s_L = vel_L(idx) - c_L*Ms_L
+            s_R = vel_R(idx) + c_R*Ms_R
+            s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))


Inconsistent use of floating point literal notation. Line 1804, 1806, 1809, and 1814 use 5e-1_wp while other parts of the codebase use 5.e-1_wp (with decimal point). Should use 5.e-1_wp for consistency with established patterns in the codebase.

Suggested change

pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

pres_SL = 5.e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5.e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

Copilot · 2025-09-17T03:35:04Z

src/common/m_variables_conversion.fpp

+            pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))
+            pres_SR = pres_SL
+            Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &
+                                   (pres_SL/pres_L - 1._wp)*pres_L/ &
+                                   ((pres_L + pi_inf_L/(1._wp + gamma_L)))))
+            Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &
+                                   (pres_SR/pres_R - 1._wp)*pres_R/ &
+                                   ((pres_R + pi_inf_R/(1._wp + gamma_R)))))
+            s_L = vel_L(idx) - c_L*Ms_L
+            s_R = vel_R(idx) + c_R*Ms_R
+            s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))


Inconsistent use of floating point literal notation. Line 1804, 1806, 1809, and 1814 use 5e-1_wp while other parts of the codebase use 5.e-1_wp (with decimal point). Should use 5.e-1_wp for consistency with established patterns in the codebase.

Suggested change

pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

pres_SL = 5.e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5.e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

Copilot · 2025-09-17T03:35:04Z

src/common/m_variables_conversion.fpp

+            pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))
+            pres_SR = pres_SL
+            Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &
+                                   (pres_SL/pres_L - 1._wp)*pres_L/ &
+                                   ((pres_L + pi_inf_L/(1._wp + gamma_L)))))
+            Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &
+                                   (pres_SR/pres_R - 1._wp)*pres_R/ &
+                                   ((pres_R + pi_inf_R/(1._wp + gamma_R)))))
+            s_L = vel_L(idx) - c_L*Ms_L
+            s_R = vel_R(idx) + c_R*Ms_R
+            s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))


Inconsistent use of floating point literal notation. Line 1804, 1806, 1809, and 1814 use 5e-1_wp while other parts of the codebase use 5.e-1_wp (with decimal point). Should use 5.e-1_wp for consistency with established patterns in the codebase.

Suggested change

pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

pres_SL = 5.e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5.e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

Copilot · 2025-09-17T03:35:05Z

src/common/m_variables_conversion.fpp

+            pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))
+            pres_SR = pres_SL
+            Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &
+                                   (pres_SL/pres_L - 1._wp)*pres_L/ &
+                                   ((pres_L + pi_inf_L/(1._wp + gamma_L)))))
+            Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &
+                                   (pres_SR/pres_R - 1._wp)*pres_R/ &
+                                   ((pres_R + pi_inf_R/(1._wp + gamma_R)))))
+            s_L = vel_L(idx) - c_L*Ms_L
+            s_R = vel_R(idx) + c_R*Ms_R
+            s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))


Inconsistent use of floating point literal notation. Line 1804, 1806, 1809, and 1814 use 5e-1_wp while other parts of the codebase use 5.e-1_wp (with decimal point). Should use 5.e-1_wp for consistency with established patterns in the codebase.

Suggested change

pres_SL = 5e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

pres_SL = 5.e-1_wp*(pres_L + pres_R + rho_avg*c_avg*(vel_L(idx) - vel_R(idx)))

pres_SR = pres_SL

Ms_L = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_L)/(1._wp + gamma_L))* &

(pres_SL/pres_L - 1._wp)*pres_L/ &

((pres_L + pi_inf_L/(1._wp + gamma_L)))))

Ms_R = max(1._wp, sqrt(1._wp + ((5.e-1_wp + gamma_R)/(1._wp + gamma_R))* &

(pres_SR/pres_R - 1._wp)*pres_R/ &

((pres_R + pi_inf_R/(1._wp + gamma_R)))))

s_L = vel_L(idx) - c_L*Ms_L

s_R = vel_R(idx) + c_R*Ms_R

s_S = 5.e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))

Copilot · 2025-09-17T03:35:05Z

src/common/m_variables_conversion.fpp

+            s_S = 5e-1_wp*((vel_L(idx) + vel_R(idx)) + (pres_L - pres_R)/(rho_avg*c_avg))
+        end if
+
+        ! ! follows Einfeldt et al.


Double comment marker ! ! is inconsistent with standard single comment style used elsewhere in the codebase. Should use single ! for consistency.

Suggested change

! ! follows Einfeldt et al.

! follows Einfeldt et al.

Malmahrouqi3 added 7 commits June 29, 2025 02:56

s_compute_wave_speed

967c128

low-stakes refactoring & lint/format

89280ad

fixed few errors

3bfa9f4

quick fix

ddaa1b6

simple fix

12eabf4

removed &

4e2a439

remove allocatable from pointers

b684a4e

Copilot AI review requested due to automatic review settings June 29, 2025 23:03

Malmahrouqi3 requested a review from a team as a code owner June 29, 2025 23:03

qodo-merge-pro bot added the Review effort 4/5 label Jun 29, 2025

Copilot AI reviewed Jun 29, 2025

View reviewed changes

src/simulation/m_riemann_solvers.fpp Show resolved Hide resolved

src/common/m_variables_conversion.fpp Show resolved Hide resolved

m_riemann_solvers cleanup & format/lint

6fb8c65

Malmahrouqi3 force-pushed the refactor branch from 84f4189 to 6fb8c65 Compare June 29, 2025 23:16

sbryngelson reviewed Jun 30, 2025

View reviewed changes

src/common/m_variables_conversion.fpp Outdated Show resolved Hide resolved

sbryngelson reviewed Jun 30, 2025

View reviewed changes

Malmahrouqi3 mentioned this pull request Jul 1, 2025

Refactor m_riemann_solvers Module (HLLC Solver Subroutine) #912

Merged

sbryngelson reviewed Jul 1, 2025

View reviewed changes

sbryngelson and others added 3 commits July 1, 2025 13:12

Merge branch 'master' into refactor

dd158d0

Merge branch 'master' into refactor

46de417

lint-fix

dcfc3e0

sbryngelson marked this pull request as draft July 19, 2025 21:41

corrected something

f3cde3e

Malmahrouqi3 force-pushed the refactor branch from 2b7053e to f3cde3e Compare August 18, 2025 22:29

Malmahrouqi3 added 2 commits August 18, 2025 18:29

Merge branch 'MFlowCode:master' into refactor

156ec55

Merge branch 'master' into refactor

b6a352e

Malmahrouqi3 marked this pull request as ready for review September 2, 2025 00:11

Merge branch 'master' into refactor

3c4b4e1

sbryngelson self-requested a review September 7, 2025 11:31

sbryngelson approved these changes Sep 7, 2025

View reviewed changes

Merge branch 'master' into refactor

797c40f

sbryngelson approved these changes Sep 12, 2025

View reviewed changes

qodo-merge-pro bot reviewed Sep 12, 2025

View reviewed changes

src/common/m_variables_conversion.fpp Show resolved Hide resolved

src/common/m_variables_conversion.fpp Show resolved Hide resolved

sbryngelson approved these changes Sep 12, 2025

View reviewed changes

Malmahrouqi3 and others added 4 commits September 15, 2025 14:27

undid all changes, retained s_compute_wave_speed

676082e

minor changes

f5e8c52

Merge branch 'master' into refactor

e9bc89c

Merge branch 'master' into refactor

89064af

sbryngelson self-requested a review September 17, 2025 03:33

sbryngelson approved these changes Sep 17, 2025

View reviewed changes

sbryngelson requested a review from Copilot September 17, 2025 03:33

Copilot AI reviewed Sep 17, 2025

View reviewed changes

sbryngelson approved these changes Sep 19, 2025

View reviewed changes

sbryngelson approved these changes Sep 22, 2025

View reviewed changes

Refactor m_riemann_solvers Module (Non-Solver Subroutines) #908

Are you sure you want to change the base?

Refactor m_riemann_solvers Module (Non-Solver Subroutines) #908

Uh oh!

Conversation

Malmahrouqi3 commented Jun 29, 2025 • edited by qodo-merge-pro bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

User description

Description

PR Type

Description

Diagram Walkthrough

File Walkthrough

Uh oh!

qodo-merge-pro bot commented Jun 29, 2025

PR Reviewer Guide 🔍

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

qodo-merge-pro bot commented Jun 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

Malmahrouqi3 commented Jun 29, 2025

Uh oh!

codecov bot commented Jun 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

sbryngelson commented Jun 30, 2025

Uh oh!

Malmahrouqi3 commented Jun 30, 2025

Uh oh!

Uh oh!

sbryngelson Jun 30, 2025

Choose a reason for hiding this comment

Uh oh!

Malmahrouqi3 Jun 30, 2025

Choose a reason for hiding this comment

Uh oh!

sbryngelson commented Jun 30, 2025

Uh oh!

Malmahrouqi3 commented Jul 1, 2025

Uh oh!

sbryngelson commented Jul 1, 2025

Uh oh!

sbryngelson Jul 1, 2025

Choose a reason for hiding this comment

Uh oh!

Malmahrouqi3 Jul 1, 2025

Choose a reason for hiding this comment

Uh oh!

Malmahrouqi3 commented Sep 2, 2025

Uh oh!

qodo-merge-pro bot commented Sep 2, 2025

PR Reviewer Guide 🔍

Uh oh!

qodo-merge-pro bot commented Sep 2, 2025

PR Code Suggestions ✨

Examples:

Solution Walkthrough:

Before:

After:

Uh oh!

Malmahrouqi3 commented Sep 2, 2025

Uh oh!

Malmahrouqi3 commented Sep 7, 2025

Uh oh!

sbryngelson commented Sep 12, 2025

Uh oh!

Uh oh!

Uh oh!

sbryngelson commented Sep 13, 2025

Uh oh!

Refactor `m_riemann_solvers` Module (Non-Solver Subroutines) #908

Refactor `m_riemann_solvers` Module (Non-Solver Subroutines) #908

Malmahrouqi3 commented Jun 29, 2025 •

edited by qodo-merge-pro bot

Loading

qodo-merge-pro bot commented Jun 29, 2025 •

edited

Loading

codecov bot commented Jun 30, 2025 •

edited

Loading