Fix k_v and k_g module-level variables not initialized to dflt_real#1184
Fix k_v and k_g module-level variables not initialized to dflt_real#1184sbryngelson wants to merge 2 commits into
Conversation
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Nitpicks 🔍
|
|
CodeAnt AI finished reviewing your PR. |
There was a problem hiding this comment.
Pull request overview
Initializes module-level thermal conductivity scalars (k_v, k_g) to the default real value to match the initialization pattern used by other bubble parameters and avoid uninitialized module state.
Changes:
- Initialize module-level
k_valongsidebub_pp%k_v. - Initialize module-level
k_galongsidebub_pp%k_g.
Every other bubble parameter follows the pattern of initializing both bub_pp%var and the module scalar, but k_v and k_g skip the module scalar initialization. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
0297772 to
20af2d3
Compare
k_v and k_g are allocatable arrays that are only allocated in s_initialize_bubbles_model when bubbles_euler .and. .not. polytropic. Assigning a scalar to them in s_assign_default_values_to_user_inputs, which runs before allocation, is invalid Fortran and causes a runtime error. Remove the premature array assignments; bub_pp%k_v/k_g (scalars) are correctly initialized and the arrays are populated from them later in s_initialize_bubble_vars after allocation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/simulation/m_global_parameters.fpp">
<violation number="1" location="src/simulation/m_global_parameters.fpp:703">
P1: Initialize the module-level scalars `k_v` and `k_g` alongside the derived-type fields to avoid leaving them undefined.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1184 +/- ##
=======================================
Coverage 44.05% 44.05%
=======================================
Files 70 70
Lines 20498 20498
Branches 1990 1990
=======================================
Hits 9030 9030
Misses 10329 10329
Partials 1139 1139 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Summary
Severity: HIGH — module-level
k_vandk_gare left uninitialized.File:
src/simulation/m_global_parameters.fpp, lines 703-704Every bubble parameter follows the pattern
bub_pp%var = dflt_real; var = dflt_real, initializing both the derived-type field and the module-level scalar. Butk_vandk_g(thermal conductivities for vapor and gas) skip the module scalar initialization.Before
After
Why this went undetected
Module-level variables may happen to be zero-initialized by the compiler or OS in many environments, masking the missing explicit initialization.
Test plan
🤖 Generated with Claude Code
Fixes #1204