Fix y-velocity perturbation using already-modified x-velocity

[sbryngelson]

User description

Summary

• Fix s_perturb_surrounding_flow in m_perturbation.fpp where the y-velocity perturbation reads the x-velocity after it has already been modified, producing an unintended coupled perturbation.

Bug Details

The perturbation code modifies x-velocity in place, then uses the modified value for the y-perturbation:

q_prim_vf(mom_idx%beg)%sf(i,j,k) = (1 + r) * vx    ! line 86: vx overwritten with (1+r)*vx
q_prim_vf(mom_idx%end)%sf(i,j,k) = r * vx_modified   ! line 87: reads (1+r)*vx instead of vx

The y-velocity ends up as r * (1+r) * vx_original instead of the intended r * vx_original. This introduces an unintended (1+r) scaling factor in the y-perturbation, coupling it to the x-perturbation magnitude.

Fix

Swap the order of the two assignments so the y-velocity is computed from the original x-velocity before x-velocity is modified:

q_prim_vf(mom_idx%end)%sf(i,j,k) = r * vx            ! y-vel from original x-vel
q_prim_vf(mom_idx%beg)%sf(i,j,k) = (1 + r) * vx      ! then modify x-vel

Test plan

• Flow perturbation cases produce physically consistent velocity fields
• y-velocity perturbation magnitude matches x-velocity perturbation magnitude (same rand_real scaling)

🤖 Generated with Claude Code

---

CodeAnt-AI Description

Fix y-velocity perturbation order so y uses original x-velocity

What Changed

• The y-velocity perturbation now uses the original x-velocity value before x is modified, preventing an extra (1+r) scaling on y
• The x-velocity perturbation is applied afterwards as (1 + r) * x, preserving the intended independent scalings
• Surrounding-flow perturbations for volume fraction keep the same random scaling behavior

Impact

✅ Correct y-velocity scaling
✅ Consistent surrounding flow perturbations
✅ Fewer unintended coupled velocity errors

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

Fixes #1222

[codeant-ai]

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 ·
Reddit ·
LinkedIn

[coderabbitai]

Warning

Rate limit exceeded

@sbryngelson has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 19 minutes and 3 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codeant-ai]

Nitpicks 🔍

🔒 No security issues identified

⚡ Recommended areas for review Perturbation ordering fix The PR reorders the two assignments so the y-perturbation reads the original x-velocity before x is modified. Confirm this change fixes the previously reported coupled scaling in all uses of s_perturb_surrounding_flow and that test cases verify y-velocity no longer carries the extra (1+r) factor. Repeated array indexing / clarity The new code computes perturbations by repeatedly indexing into q_prim_vf(...%beg)%sf(i,j,k). This is both slightly inefficient and harder to audit for correctness. Cache the original value in a local scalar to improve clarity and avoid accidental use of a modified value. Potential aliasing / memory overlap The code reads from and then writes to entries of the same array (q_prim_vf) at adjacent component indices (mom_idx%beg and mom_idx%end). If those indices ever alias or map to the same memory in some configuration, the fix may still produce incorrect values. Review index definitions and consider making the original value explicit before mutation.

[codeant-ai]

CodeAnt AI finished reviewing your PR.

[Copilot]

Pull request overview

This PR fixes a bug in the flow perturbation logic where the y-velocity perturbation incorrectly used the already-modified x-velocity value instead of the original value, resulting in an unintended coupling between x and y perturbations.

Changes:

• Swapped the order of x-velocity and y-velocity assignment operations to ensure y-velocity is computed from the original x-velocity before x-velocity is modified

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 44.05%. Comparing base (84c46e0) to head (eb8ecc1).
⚠️ Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
src/pre_process/m_perturbation.fpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1216   +/-   ##
=======================================
  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.
📢 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]

Superseded by #1241 (batched low-risk fixes)