Skip to content

Extrusion v3#1349

Open
DimAdam-01 wants to merge 13 commits intoMFlowCode:masterfrom
DimAdam-01:ExtrusionV3
Open

Extrusion v3#1349
DimAdam-01 wants to merge 13 commits intoMFlowCode:masterfrom
DimAdam-01:ExtrusionV3

Conversation

@DimAdam-01
Copy link
Copy Markdown
Contributor

Description

Summarize your changes and the motivation behind them.

IC Extrusion: The workflow for extending Initial Conditions to higher dimensions has been simplified. The updated methodology is now more robust and user-friendly.
Documentation & Examples: To assist users with this new methodology, three new reference examples have been uploaded to the repository (one 1D case and two 2D cases)

Fixes #(issue)

Type of change

-[x] A current methodology being more user-friendly

Testing

How did you test your changes?

  • 1st Test, 1D Flamelet.
  • 2nd Test, 2D Premixed Flame Vortex interaction
Flame_Vortex_Interaction.mp4

-[x] 3rd Test, 2D Premixed Flame with perturbed flame front

Flame_Insta.mp4

Checklist

  • I added or updated tests for new behavior
  • I updated documentation if user-facing behavior changed

See the developer guide for full coding standards.

GPU changes (expand if you modified src/simulation/)
  • GPU results match CPU results
  • Tested on NVIDIA GPU or AMD GPU

AI code reviews

Reviews are not triggered automatically. To request a review, comment on the PR:

  • @coderabbitai review — incremental review (new changes only)
  • @coderabbitai full review — full review from scratch
  • /review — Qodo review
  • /improve — Qodo code suggestions
  • @claude full review — Claude full review (also triggers on PR open/reopen/ready)
  • Add label claude-full-review — Claude full review via label

@DimAdam-01 DimAdam-01 requested a review from sbryngelson as a code owner April 1, 2026 18:25
@qodo-code-review
Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Add premixed flame IC cases and refactor extrusion workflow with configurable paths

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add two new hardcoded IC cases (271, 272) for premixed flame simulations
  - Case 271: Premixed flame vortex interaction with dual counter-rotating vortices
  - Case 272: Premixed flame instability with sinusoidal front perturbation
• Refactor IC extrusion workflow to use configurable files_dir and file_extension parameters
  - Replace hardcoded path and filename pattern with user-configurable parameters
  - Improve MPI communication for new parameters via broadcast
• Add three reference example cases with complete configuration files
  - 1D flamelet case with San Diego mechanism
  - 2D premixed flame vortex interaction case
  - 2D premixed flame Landau instability case
• Update parameter definitions and test suite for new IC extrusion examples
Diagram
flowchart LR
  A["Hardcoded IC Cases<br/>271, 272"] -->|"Vortex & Instability<br/>Perturbations"| B["2D Premixed<br/>Flame Simulations"]
  C["Configurable<br/>files_dir & file_extension"] -->|"Replace hardcoded<br/>init_dir"| D["Flexible IC<br/>Extrusion"]
  E["Reference Examples<br/>1D, 2D cases"] -->|"Complete setup<br/>with case.py"| F["User-friendly<br/>Workflow"]
  D --> B
  F --> B
Loading

Grey Divider

File Changes

1. src/common/include/2dHardcodedIC.fpp ✨ Enhancement +0/-0

Add new premixed flame IC cases 271 and 272

src/common/include/2dHardcodedIC.fpp


2. src/common/include/ExtrusionHardcodedIC.fpp ✨ Enhancement +0/-0

Refactor extrusion to use configurable file parameters

src/common/include/ExtrusionHardcodedIC.fpp


3. src/pre_process/m_global_parameters.fpp ✨ Enhancement +0/-0

Add files_dir and file_extension global parameters

src/pre_process/m_global_parameters.fpp


View more (13)
4. src/pre_process/m_start_up.fpp ✨ Enhancement +0/-0

Include new parameters in startup configuration reading

src/pre_process/m_start_up.fpp


5. src/pre_process/m_mpi_proxy.fpp ✨ Enhancement +0/-0

Broadcast new file parameters across MPI processes

src/pre_process/m_mpi_proxy.fpp


6. examples/2D_premixed_flame_vortex/case.py 📝 Documentation +93/-0

Add complete 2D premixed flame vortex case configuration

examples/2D_premixed_flame_vortex/case.py


7. examples/2D_premixed_landau_insta/case.py 📝 Documentation +0/-0

Add complete 2D premixed flame Landau instability case

examples/2D_premixed_landau_insta/case.py


8. examples/1D_flamelet/case.py 📝 Documentation +73/-0

Add complete 1D flamelet case configuration

examples/1D_flamelet/case.py


9. examples/1D_flamelet/sandiego.yaml 📝 Documentation +303/-0

Add San Diego chemical mechanism for flamelet case

examples/1D_flamelet/sandiego.yaml


10. toolchain/mfc/test/cases.py 🧪 Tests +0/-0

Register new example cases in test suite

toolchain/mfc/test/cases.py


11. toolchain/mfc/params/definitions.py ✨ Enhancement +0/-0

Define files_dir and file_extension parameters

toolchain/mfc/params/definitions.py


12. toolchain/mfc/params/descriptions.py 📝 Documentation +0/-0

Add parameter descriptions for file configuration

toolchain/mfc/params/descriptions.py


13. toolchain/mfc/params/namelist_parser.py ✨ Enhancement +0/-0

Add new parameters to namelist parser

toolchain/mfc/params/namelist_parser.py


14. tests/0D1E22F3/golden-metadata.txt 🧪 Tests +0/-0

Update test metadata with build configuration

tests/0D1E22F3/golden-metadata.txt


15. docs/documentation/case.md 📝 Documentation +2/-2

Update documentation for IC extrusion workflow

docs/documentation/case.md


16. tests/0D1E22F3/golden.txt Additional files +0/-0

...

tests/0D1E22F3/golden.txt


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown
Contributor

qodo-code-review bot commented Apr 1, 2026

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0)

Grey Divider


Action required

1. files_extension parameter typo 📘 Rule violation ≡ Correctness
Description
The toolchain fallback namelist parameter list (and docs) use files_extension, but the Fortran
namelist and parameter registry use file_extension. This breaks consistent parameter registration
and can cause cases using file_extension to be rejected or undocumented.
Code

toolchain/mfc/params/namelist_parser.py[R45-46]

+        "files_dir",
+        "files_extension",
Evidence
PR Compliance ID 6 requires new parameters to be consistently registered/wired across the toolchain
and Fortran namelist. The PR registers file_extension in the toolchain and Fortran namelist, but
introduces the mismatched name files_extension in the toolchain fallback parser and documentation.

CLAUDE.md
toolchain/mfc/params/namelist_parser.py[45-47]
src/pre_process/m_start_up.fpp[84-88]
toolchain/mfc/params/definitions.py[1048-1051]
docs/documentation/case.md[259-266]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The parameter name is inconsistent: `files_extension` is used in the toolchain fallback namelist parameter list (and in docs), while the actual registered/Fortran parameter name is `file_extension`.

## Issue Context
This inconsistency can cause parameter parsing/validation failures (especially when the fallback parameter set is used) and violates the requirement that new parameters be registered consistently across sources-of-truth.

## Fix Focus Areas
- toolchain/mfc/params/namelist_parser.py[45-47]
- docs/documentation/case.md[259-266]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Hardcoded velocity indices 🐞 Bug ≡ Correctness
Description
Hardcoded IC case (271) writes vortex velocities to q_prim_vf(2) and q_prim_vf(3) instead of
using the momentum index bounds (momxb/momxe). This can write into the wrong primitive variables
whenever the state-vector layout changes (e.g., additional equations/fields), corrupting the
initialized state.
Code

src/common/include/2dHardcodedIC.fpp[R275-293]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(2)%sf(i, j, 0) = q_prim_vf(2)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(3)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
Evidence
Elsewhere in the same hardcoded IC file, momentum components are referenced via momxb/momxe (not
numeric literals). Additionally, momxb/momxe are derived from mom_idx%beg/%end in global
parameters, so they are not guaranteed to be fixed to 2/3 across configurations.

src/common/include/2dHardcodedIC.fpp[44-56]
src/common/include/2dHardcodedIC.fpp[275-292]
src/pre_process/m_global_parameters.fpp[201-211]
src/pre_process/m_global_parameters.fpp[805-826]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Case (271) assigns velocity perturbations using fixed indices `q_prim_vf(2)` and `q_prim_vf(3)`. These indices are not stable across different equation sets and can point to the wrong fields.

## Issue Context
- Other hardcoded IC cases use `momxb`, `momxe`, or `momxb+1`.
- `momxb/momxe` are derived from `mom_idx` bounds and can shift with configuration.

## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-292]
- src/pre_process/m_global_parameters.fpp[805-826]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

3. Extrusion docs typos 🐞 Bug ⚙ Maintainability
Description
The updated documentation introduces a typo ("etup") and an inconsistent filename-token
(files_extension vs file_extension), which can mislead users configuring extrusion. This makes
the new workflow harder to follow and increases misconfiguration risk.
Code

docs/documentation/case.md[R265-266]

+etup: Only requires specifying `files_dir` and filename pattern via `file_extension`. The files are located, for example, at `examples/1D_flamelet/IC`, and their format is `prim.XX.YY.files_extension.dat`.
+Implementation: All variables and file handling are managed in the `case.py` file of the simulation.
Evidence
The docs now reference file_extension but also show a filename format containing
files_extension, and the "Setup" label is misspelled; meanwhile the toolchain/Fortran parameter is
file_extension (singular).

docs/documentation/case.md[262-267]
toolchain/mfc/params/definitions.py[1048-1051]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs for extrusion contain a typo and inconsistent parameter/token naming (`files_extension` vs `file_extension`).

## Issue Context
Users will likely copy/paste the documented pattern/parameter names into their cases.

## Fix Focus Areas
- docs/documentation/case.md[262-267]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@sbryngelson sbryngelson marked this pull request as draft April 1, 2026 18:28
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 1, 2026

📝 Walkthrough

Walkthrough

This pull request introduces a new 1D flamelet example case and updates related documentation. A .gitignore rule is added to exclude example data files matching the pattern examples/**/IC/*.dat. Documentation is updated to reflect a revised workflow for dimensional extrusion patches using files_dir and file_extension parameters. Two new files are added: a Python script that generates a JSON simulation configuration using Cantera, and a Cantera mechanism file defining a hydrogen/oxygen/nitrogen reacting mixture with thermodynamic and transport properties.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Title check ❓ Inconclusive The title 'Extrusion v3' is vague and generic, offering minimal insight into the actual changes beyond suggesting a version iteration. Replace with a more descriptive title that highlights the main improvement, such as 'Simplify Initial Condition extrusion workflow' or 'Improve IC extrusion user experience with new examples'.
✅ Passed checks (2 passed)
Check name Status Explanation
Description check ✅ Passed The description covers the main changes, includes testing details with attachments, and follows most template sections; however, the 'Type of change' section is unclear and uses non-standard formatting.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


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

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

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
.gitignore (1)

57-57: Redundant ignore pattern (no functional change).

Line 57 is already covered by examples/**/*.dat (Line 64), so this new rule is a no-op. Consider removing it to keep ignore rules minimal.


ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 96117184-e389-41b7-b7bb-97731b0c2155

📥 Commits

Reviewing files that changed from the base of the PR and between 7da6212 and a39c5ef.

⛔ Files ignored due to path filters (42)
  • examples/1D_flamelet/IC/prim.1.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.10.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.11.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.12.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.13.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.14.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.2.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.3.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.4.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.5.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.6.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.7.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.8.00.000000.dat is excluded by !**/*.dat
  • examples/1D_flamelet/IC/prim.9.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.1.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.10.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.11.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.12.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.13.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.14.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.2.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.3.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.4.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.5.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.6.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.7.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.8.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_flame_vortex/IC/prim.9.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.1.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.10.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.11.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.12.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.13.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.14.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.2.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.3.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.4.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.5.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.6.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.7.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.8.00.000000.dat is excluded by !**/*.dat
  • examples/2D_premixed_landau_insta/IC/prim.9.00.000000.dat is excluded by !**/*.dat
📒 Files selected for processing (17)
  • .gitignore
  • docs/documentation/case.md
  • examples/1D_flamelet/case.py
  • examples/1D_flamelet/sandiego.yaml
  • examples/2D_premixed_flame_vortex/case.py
  • examples/2D_premixed_landau_insta/case.py
  • src/common/include/2dHardcodedIC.fpp
  • src/common/include/ExtrusionHardcodedIC.fpp
  • src/pre_process/m_global_parameters.fpp
  • src/pre_process/m_mpi_proxy.fpp
  • src/pre_process/m_start_up.fpp
  • tests/0D1E22F3/golden-metadata.txt
  • tests/0D1E22F3/golden.txt
  • toolchain/mfc/params/definitions.py
  • toolchain/mfc/params/descriptions.py
  • toolchain/mfc/params/namelist_parser.py
  • toolchain/mfc/test/cases.py

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 1, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.13%. Comparing base (cf13fa1) to head (0374f70).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1349      +/-   ##
==========================================
- Coverage   64.88%   64.13%   -0.75%     
==========================================
  Files          70       70              
  Lines       18249    18337      +88     
  Branches     1507     1511       +4     
==========================================
- Hits        11841    11761      -80     
- Misses       5446     5534      +88     
- Partials      962     1042      +80     

☔ 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.

@DimAdam-01 DimAdam-01 marked this pull request as ready for review April 10, 2026 13:40
@qodo-code-review
Copy link
Copy Markdown
Contributor

qodo-code-review bot commented Apr 10, 2026

Code Review by Qodo

🐞 Bugs (5)   📘 Rule violations (3)   📎 Requirement gaps (0)   🎨 UX Issues (0)
🐞\ ≡ Correctness (3) ⚙ Maintainability (2) ⭐ New (3)
📘\ ≡ Correctness (2) ⚙ Maintainability (1) ⭐ New (2)

Grey Divider


Action required

1. files_dir undefined in simulation 📘
Description
ExtrusionHardcodedIC.fpp now references files_dir and file_extension, but the simulation-side
m_global_parameters/namelist/MPI broadcast do not define or distribute these parameters. This can
break simulation compilation or cause rank-to-rank mismatches at runtime when using extrusion-based
ICs.
Code

src/common/include/ExtrusionHardcodedIC.fpp[62]

+            fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Evidence
PR Compliance ID 7 requires new parameters to be added consistently across definitions, Fortran
declarations, and namelist bindings. The PR introduces usage of files_dir/file_extension in a
common include used by simulation, but simulation input parsing and global parameters do not include
these new variables.

CLAUDE.md
src/common/include/ExtrusionHardcodedIC.fpp[59-63]
src/simulation/m_global_parameters.fpp[24-29]
src/simulation/m_start_up.fpp[84-114]
src/simulation/m_mpi_proxy.fpp[58-66]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new parameters `files_dir` and `file_extension` are used by code included in the simulation build (`ExtrusionHardcodedIC.fpp`), but they are only declared/bound/broadcast in `src/pre_process`. Simulation must also declare them in `m_global_parameters`, read them from `simulation.inp` via the `user_inputs` namelist, and broadcast them to all ranks.

## Issue Context
`src/simulation/m_ib_patches.fpp` includes `ExtrusionHardcodedIC.fpp`, which now constructs file names using `files_dir` and `file_extension`.

## Fix Focus Areas
- src/simulation/m_global_parameters.fpp[24-35]
- src/simulation/m_start_up.fpp[84-114]
- src/simulation/m_mpi_proxy.fpp[58-70]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Extrusion reads rank-00 only 🐞
Description
The extrusion reader hard-codes the middle filename field to .00. (prim.<var>.00.<ext>.dat), so
it cannot read data produced with parallel I/O that is split across ranks
(prim.<var>.<rank>.<tstep>.dat). This can lead to incomplete/incorrect extruded initial conditions
or runtime failures when users follow the documented prim.XX.YY.file_extension.dat naming.
Code

src/common/include/ExtrusionHardcodedIC.fpp[62]

+            fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Evidence
Docs describe an XX.YY filename format, and the codebase writes prim.*.<proc_rank>.* files (YY
varies) in pre_process output; however, the extrusion reader always uses YY="00", so it cannot
consume multi-rank outputs as-is.

src/common/include/ExtrusionHardcodedIC.fpp[59-67]
src/pre_process/m_data_output.fpp[162-166]
docs/documentation/case.md[259-267]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
IC extrusion currently assumes the source data files have processor-rank field `YY=00` in `prim.XX.YY.<ext>.dat`. This prevents extruding from source datasets produced with MPI/parallel I/O where data is split across multiple `YY` files.

### Issue Context
- The repository writes files as `prim.<var>.<proc_rank>.<t_step>.dat`.
- Documentation states the format is `prim.XX.YY.file_extension.dat` without stating `YY` must be `00`.

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[59-67]
- src/pre_process/m_data_output.fpp[162-166]
- docs/documentation/case.md[259-267]

### Fix options (pick one)
1) **Implement support**: read and merge/sort data across all available `YY` partitions for each `XX` (most robust).
2) **Add a parameter**: e.g., `files_rank` (I2.2) and build filenames with that rank instead of hard-coding `00`.
3) **Clarify & enforce**: update docs to require `YY=00` / serial output, and add an explicit runtime check + clear abort message when expected files are missing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. files_extension parameter typo 📘
Description
The toolchain fallback namelist parameter list (and docs) use files_extension, but the Fortran
namelist and parameter registry use file_extension. This breaks consistent parameter registration
and can cause cases using file_extension to be rejected or undocumented.
Code

toolchain/mfc/params/namelist_parser.py[R45-46]

+        "files_dir",
+        "files_extension",
Evidence
PR Compliance ID 6 requires new parameters to be consistently registered/wired across the toolchain
and Fortran namelist. The PR registers file_extension in the toolchain and Fortran namelist, but
introduces the mismatched name files_extension in the toolchain fallback parser and documentation.

CLAUDE.md
toolchain/mfc/params/namelist_parser.py[45-47]
src/pre_process/m_start_up.fpp[84-88]
toolchain/mfc/params/definitions.py[1048-1051]
docs/documentation/case.md[259-266]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The parameter name is inconsistent: `files_extension` is used in the toolchain fallback namelist parameter list (and in docs), while the actual registered/Fortran parameter name is `file_extension`.
## Issue Context
This inconsistency can cause parameter parsing/validation failures (especially when the fallback parameter set is used) and violates the requirement that new parameters be registered consistently across sources-of-truth.
## Fix Focus Areas
- toolchain/mfc/params/namelist_parser.py[45-47]
- docs/documentation/case.md[259-266]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (1)
4. Hardcoded velocity indices 🐞
Description
Hardcoded IC case (271) writes vortex velocities to q_prim_vf(2) and q_prim_vf(3) instead of
using the momentum index bounds (momxb/momxe). This can write into the wrong primitive variables
whenever the state-vector layout changes (e.g., additional equations/fields), corrupting the
initialized state.
Code

src/common/include/2dHardcodedIC.fpp[R275-293]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(2)%sf(i, j, 0) = q_prim_vf(2)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(3)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
Evidence
Elsewhere in the same hardcoded IC file, momentum components are referenced via momxb/momxe (not
numeric literals). Additionally, momxb/momxe are derived from mom_idx%beg/%end in global
parameters, so they are not guaranteed to be fixed to 2/3 across configurations.

src/common/include/2dHardcodedIC.fpp[44-56]
src/common/include/2dHardcodedIC.fpp[275-292]
src/pre_process/m_global_parameters.fpp[201-211]
src/pre_process/m_global_parameters.fpp[805-826]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Case (271) assigns velocity perturbations using fixed indices `q_prim_vf(2)` and `q_prim_vf(3)`. These indices are not stable across different equation sets and can point to the wrong fields.
## Issue Context
- Other hardcoded IC cases use `momxb`, `momxe`, or `momxb+1`.
- `momxb/momxe` are derived from `mom_idx` bounds and can shift with configuration.
## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-292]
- src/pre_process/m_global_parameters.fpp[805-826]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

5. Non-2-space indentation added 📘
Description
The newly added case (271)/case (272) blocks use indentation that does not follow the required
2-space indentation style. This reduces consistency and violates the style compliance requirement.
Code

src/common/include/2dHardcodedIC.fpp[R275-331]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(momxb)%sf(i, j, 0) = q_prim_vf(momxb)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(momxe)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
+        @: HardcodedReadValues()
+
+        y_center = y0_ref
+        y_dist = y_cc(j) - y_center
+        wave_phase = 2.0_wp*pi*Nwaves*(y_dist/Ly_param)
+        front_shift = A_param*sin(wave_phase)
+
+        x_mapped = x_cc(i) - front_shift
+
+        if (x_mapped <= x_coords(1)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(1, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else if (x_mapped >= x_coords(xRows)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(xRows, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else
+            idx_lo = 1; idx_hi = xRows
+            do while (idx_hi - idx_lo > 1)
+                idx_mid = (idx_lo + idx_hi)/2
+                if (x_coords(idx_mid) <= x_mapped) then
+                    idx_lo = idx_mid
+                else
+                    idx_hi = idx_mid
+                end if
+            end do
+
+            interp_wt = (x_mapped - x_coords(idx_lo))/(x_coords(idx_hi) - x_coords(idx_lo))  ! weight in [0,1)
+
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = (1.0_wp - interp_wt)*stored_values(idx_lo, 1, &
+                          & v) + interp_wt*stored_values(idx_hi, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        end if
Evidence
PR Compliance ID 9 requires 2-space indentation in new or modified Fortran code. The added `case
(271)/case (272)` blocks are indented with more than 2 spaces throughout.

CLAUDE.md
src/common/include/2dHardcodedIC.fpp[275-331]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New code added under `case (271)` and `case (272)` does not follow the required 2-space indentation convention.

## Issue Context
This affects only the newly added blocks for premixed flame vortices/instability initialization.

## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. IC path truncation risk 🐞
Description
ExtrusionHardcodedIC stores full file paths into fileNames with character(len=150), while
path_len is 400 and files_dir alone can be 255 chars; long paths will be silently truncated and
then fail to open/read the IC files. This can break IC extrusion in deep directory layouts and is
hard to diagnose because truncation happens before the open() error check.
Code

src/common/include/ExtrusionHardcodedIC.fpp[45]

+    character(len=150), dimension(sys_size) :: fileNames                         !< Arrays to store all data from files
Evidence
The code constructs a full path into fileNames(f) but the buffer is only 150 characters, which is
smaller than the repo-wide max path length constant and smaller than the declared files_dir
buffer; Fortran will truncate on assignment, causing wrong paths passed to open().

src/common/include/ExtrusionHardcodedIC.fpp[38-63]
src/pre_process/m_global_parameters.fpp[20-25]
src/common/m_constants.fpp[10-22]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
IC extrusion builds file paths into `fileNames`, but `fileNames` is only `character(len=150)`. Since paths can be up to `path_len` (400) and `files_dir` is `character(len=255)`, the constructed path can be silently truncated before `open()`, leading to file-not-found at runtime.

### Issue Context
This PR already increases `fileNames` from 100 to 150, but 150 is still below `path_len` and can truncate valid paths.

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[38-55]
- src/pre_process/m_global_parameters.fpp[20-26]
- src/common/m_constants.fpp[15-22]

### Expected change
- Change `fileNames` to `character(len=path_len)` (or larger if needed).
- Consider changing `files_dir` to `character(len=path_len)` for consistency.
- Keep MPI broadcasts using `len(files_dir)` / `len(file_extension)` so counts stay consistent with the declarations.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

7. Stale extrusion header comment 🐞
Description
ExtrusionHardcodedIC.fpp’s header comment still claims filenames come from init_dir and
zeros_default, but the implementation now uses files_dir and file_extension. This
inconsistency can mislead maintainers/users when updating or debugging extrusion behavior.
Code

src/common/include/ExtrusionHardcodedIC.fpp[R51-54]

+    character(len=20)                       :: file_num_str                      !< For storing the file number as a string
+    character(len=20)                       :: zeros_part                        !< For the trailing zeros part
+    integer                                 :: ios = 0
+    integer                                 :: ios2 = 0
Evidence
The header documentation references init_dir/zeros_default even though those parameters were
removed and the code constructs names from files_dir/file_extension.

src/common/include/ExtrusionHardcodedIC.fpp[11-16]
src/common/include/ExtrusionHardcodedIC.fpp[34-36]
src/common/include/ExtrusionHardcodedIC.fpp[57-63]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The documentation block at the top of `ExtrusionHardcodedIC.fpp` still references removed parameters (`init_dir`, `zeros_default`) and no longer matches the current implementation.

### Issue Context
The implementation now builds filenames using `files_dir` and `file_extension`.

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[11-36]
- src/common/include/ExtrusionHardcodedIC.fpp[57-63]

### Expected change
- Replace `init_dir` -> `files_dir` in the comment.
- Replace `zeros_default` / `<timestep>` wording -> `file_extension` wording.
- Ensure the documented filename pattern matches the actual constructed string (including the `.00.` field if it remains hard-coded).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


8. Extrusion docs typos 🐞
Description
The updated documentation introduces a typo ("etup") and an inconsistent filename-token
(files_extension vs file_extension), which can mislead users configuring extrusion. This makes
the new workflow harder to follow and increases misconfiguration risk.
Code

docs/documentation/case.md[R265-266]

+etup: Only requires specifying `files_dir` and filename pattern via `file_extension`. The files are located, for example, at `examples/1D_flamelet/IC`, and their format is `prim.XX.YY.files_extension.dat`.
+Implementation: All variables and file handling are managed in the `case.py` file of the simulation.
Evidence
The docs now reference file_extension but also show a filename format containing
files_extension, and the "Setup" label is misspelled; meanwhile the toolchain/Fortran parameter is
file_extension (singular).

docs/documentation/case.md[262-267]
toolchain/mfc/params/definitions.py[1048-1051]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs for extrusion contain a typo and inconsistent parameter/token naming (`files_extension` vs `file_extension`).
## Issue Context
Users will likely copy/paste the documented pattern/parameter names into their cases.
## Fix Focus Areas
- docs/documentation/case.md[262-267]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

#:enddef

#:def HardcodedReadValues()
if (.not. files_loaded) then
max_files = merge(sys_size, sys_size - 1, num_dims == 1)
do f = 1, max_files
write (file_num_str, '(I0)') f
fileNames(f) = trim(init_dir) // "prim." // trim(file_num_str) // ".00." // zeros_default // ".dat"
fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. files_dir undefined in simulation 📘 Rule violation ≡ Correctness

ExtrusionHardcodedIC.fpp now references files_dir and file_extension, but the simulation-side
m_global_parameters/namelist/MPI broadcast do not define or distribute these parameters. This can
break simulation compilation or cause rank-to-rank mismatches at runtime when using extrusion-based
ICs.
Agent Prompt
## Issue description
The new parameters `files_dir` and `file_extension` are used by code included in the simulation build (`ExtrusionHardcodedIC.fpp`), but they are only declared/bound/broadcast in `src/pre_process`. Simulation must also declare them in `m_global_parameters`, read them from `simulation.inp` via the `user_inputs` namelist, and broadcast them to all ranks.

## Issue Context
`src/simulation/m_ib_patches.fpp` includes `ExtrusionHardcodedIC.fpp`, which now constructs file names using `files_dir` and `file_extension`.

## Fix Focus Areas
- src/simulation/m_global_parameters.fpp[24-35]
- src/simulation/m_start_up.fpp[84-114]
- src/simulation/m_mpi_proxy.fpp[58-70]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

#:enddef

#:def HardcodedReadValues()
if (.not. files_loaded) then
max_files = merge(sys_size, sys_size - 1, num_dims == 1)
do f = 1, max_files
write (file_num_str, '(I0)') f
fileNames(f) = trim(init_dir) // "prim." // trim(file_num_str) // ".00." // zeros_default // ".dat"
fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Extrusion reads rank-00 only 🐞 Bug ≡ Correctness

The extrusion reader hard-codes the middle filename field to .00. (prim.<var>.00.<ext>.dat), so
it cannot read data produced with parallel I/O that is split across ranks
(prim.<var>.<rank>.<tstep>.dat). This can lead to incomplete/incorrect extruded initial conditions
or runtime failures when users follow the documented prim.XX.YY.file_extension.dat naming.
Agent Prompt
### Issue description
IC extrusion currently assumes the source data files have processor-rank field `YY=00` in `prim.XX.YY.<ext>.dat`. This prevents extruding from source datasets produced with MPI/parallel I/O where data is split across multiple `YY` files.

### Issue Context
- The repository writes files as `prim.<var>.<proc_rank>.<t_step>.dat`.
- Documentation states the format is `prim.XX.YY.file_extension.dat` without stating `YY` must be `00`.

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[59-67]
- src/pre_process/m_data_output.fpp[162-166]
- docs/documentation/case.md[259-267]

### Fix options (pick one)
1) **Implement support**: read and merge/sort data across all available `YY` partitions for each `XX` (most robust).
2) **Add a parameter**: e.g., `files_rank` (I2.2) and build filenames with that rank instead of hard-coding `00`.
3) **Clarify & enforce**: update docs to require `YY=00` / serial output, and add an explicit runtime check + clear abort message when expected files are missing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@qodo-code-review
Copy link
Copy Markdown
Contributor

qodo-code-review bot commented Apr 10, 2026

Code Review by Qodo

🐞 Bugs (7)   📘 Rule violations (4)   📎 Requirement gaps (0)   🎨 UX Issues (0)
🐞\ ≡ Correctness (5) ⚙ Maintainability (2) ⭐ New (2)
📘\ ≡ Correctness (2) ⚙ Maintainability (2) ⭐ New (1)

Grey Divider


Action required

1. 1D extrusion index shift 🐞
Description
HardcodedReadValues() now computes global_offset_x for 1D using x_cc(0) - x_coords(1) without
the half-cell correction, but x_coords comes from files written with x_cb coordinates. This
makes global_offset_x round to 1 instead of 0 (via nint), shifting all 1D extruded IC samples by
one index.
Code

src/common/include/ExtrusionHardcodedIC.fpp[R98-102]

            ! Calculate offsets
            domain_xstart = x_coords(1)
            x_step = x_cc(1) - x_cc(0)
-            delta_x = merge(x_cc(0) - domain_xstart + x_step/2.0, x_cc(index_x) - domain_xstart + x_step/2.0, num_dims == 1)
+            delta_x = merge(x_cc(0) - domain_xstart, x_cc(index_x) - domain_xstart + x_step/2.0, num_dims == 1)
            global_offset_x = nint(abs(delta_x)/x_step)
Evidence
In the PR version, 1D offset uses delta_x = x_cc(0) - domain_xstart (where `domain_xstart =
x_coords(1)). But the codebase defines x_cc as the midpoint of neighboring x_cb` values, and the
simulation writes primitive output coordinates using x_cb(j) (not x_cc(j)), meaning
x_coords(1) corresponds to x_cb(0) while x_cc(0) = (x_cb(0)+x_cb(-1))/2, i.e., offset by
-dx/2. Dividing by x_step≈dx and applying nint produces a 1-cell shift in global_offset_x,
propagating to idx = i+1+global_offset_x for 1D assignment.

/src/common/include/ExtrusionHardcodedIC.fpp[98-103]
/src/pre_process/m_start_up.fpp[171-185]
/src/simulation/m_data_output.fpp[409-422]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
1D IC extrusion computes `global_offset_x` using `delta_x = x_cc(0) - x_coords(1)` (where `x_coords` is read from the first column of `prim.*.dat`). Because `prim.*` files write `x_cb(j)` as the coordinate while `x_cc` is cell-centered, this introduces a half-cell mismatch and `nint` rounds it to a full index shift.

### Issue Context
- `x_cc(0:m) = (x_cb(0:m) + x_cb(-1:(m-1)))/2` (cell centers)
- `prim.*` output uses `x_cb(j)` as the x-coordinate
- `HardcodedReadValues()` uses `global_offset_x = nint(abs(delta_x)/x_step)` and then indexes `stored_values` with `idx = i + 1 + global_offset_x`

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[98-103]

### Suggested fix
- For `num_dims == 1`, reintroduce the half-step correction when comparing `x_cc` to file coordinates, e.g.:
 - `delta_x = x_cc(0) - domain_xstart + x_step/2.0_wp`
- Add a short comment explaining that the first column in `prim.*` is `x_cb` while values are cell-centered.
- (Optional but ideal) add a small regression test covering hcid=170 on a uniform grid that verifies no one-cell shift occurs when extruding from a serial `prim.*` output.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. files_extension parameter typo 📘
Description
The toolchain fallback namelist parameter list (and docs) use files_extension, but the Fortran
namelist and parameter registry use file_extension. This breaks consistent parameter registration
and can cause cases using file_extension to be rejected or undocumented.
Code

toolchain/mfc/params/namelist_parser.py[R45-46]

+        "files_dir",
+        "files_extension",
Evidence
PR Compliance ID 6 requires new parameters to be consistently registered/wired across the toolchain
and Fortran namelist. The PR registers file_extension in the toolchain and Fortran namelist, but
introduces the mismatched name files_extension in the toolchain fallback parser and documentation.

CLAUDE.md
toolchain/mfc/params/namelist_parser.py[45-47]
src/pre_process/m_start_up.fpp[84-88]
toolchain/mfc/params/definitions.py[1048-1051]
docs/documentation/case.md[259-266]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The parameter name is inconsistent: `files_extension` is used in the toolchain fallback namelist parameter list (and in docs), while the actual registered/Fortran parameter name is `file_extension`.
## Issue Context
This inconsistency can cause parameter parsing/validation failures (especially when the fallback parameter set is used) and violates the requirement that new parameters be registered consistently across sources-of-truth.
## Fix Focus Areas
- toolchain/mfc/params/namelist_parser.py[45-47]
- docs/documentation/case.md[259-266]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Hardcoded velocity indices 🐞
Description
Hardcoded IC case (271) writes vortex velocities to q_prim_vf(2) and q_prim_vf(3) instead of
using the momentum index bounds (momxb/momxe). This can write into the wrong primitive variables
whenever the state-vector layout changes (e.g., additional equations/fields), corrupting the
initialized state.
Code

src/common/include/2dHardcodedIC.fpp[R275-293]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(2)%sf(i, j, 0) = q_prim_vf(2)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(3)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
Evidence
Elsewhere in the same hardcoded IC file, momentum components are referenced via momxb/momxe (not
numeric literals). Additionally, momxb/momxe are derived from mom_idx%beg/%end in global
parameters, so they are not guaranteed to be fixed to 2/3 across configurations.

src/common/include/2dHardcodedIC.fpp[44-56]
src/common/include/2dHardcodedIC.fpp[275-292]
src/pre_process/m_global_parameters.fpp[201-211]
src/pre_process/m_global_parameters.fpp[805-826]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Case (271) assigns velocity perturbations using fixed indices `q_prim_vf(2)` and `q_prim_vf(3)`. These indices are not stable across different equation sets and can point to the wrong fields.
## Issue Context
- Other hardcoded IC cases use `momxb`, `momxe`, or `momxb+1`.
- `momxb/momxe` are derived from `mom_idx` bounds and can shift with configuration.
## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-292]
- src/pre_process/m_global_parameters.fpp[805-826]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (2)
4. files_dir undefined in simulation 📘
Description
ExtrusionHardcodedIC.fpp now references files_dir and file_extension, but the simulation-side
m_global_parameters/namelist/MPI broadcast do not define or distribute these parameters. This can
break simulation compilation or cause rank-to-rank mismatches at runtime when using extrusion-based
ICs.
Code

src/common/include/ExtrusionHardcodedIC.fpp[62]

+            fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Evidence
PR Compliance ID 7 requires new parameters to be added consistently across definitions, Fortran
declarations, and namelist bindings. The PR introduces usage of files_dir/file_extension in a
common include used by simulation, but simulation input parsing and global parameters do not include
these new variables.

CLAUDE.md
src/common/include/ExtrusionHardcodedIC.fpp[59-63]
src/simulation/m_global_parameters.fpp[24-29]
src/simulation/m_start_up.fpp[84-114]
src/simulation/m_mpi_proxy.fpp[58-66]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new parameters `files_dir` and `file_extension` are used by code included in the simulation build (`ExtrusionHardcodedIC.fpp`), but they are only declared/bound/broadcast in `src/pre_process`. Simulation must also declare them in `m_global_parameters`, read them from `simulation.inp` via the `user_inputs` namelist, and broadcast them to all ranks.
## Issue Context
`src/simulation/m_ib_patches.fpp` includes `ExtrusionHardcodedIC.fpp`, which now constructs file names using `files_dir` and `file_extension`.
## Fix Focus Areas
- src/simulation/m_global_parameters.fpp[24-35]
- src/simulation/m_start_up.fpp[84-114]
- src/simulation/m_mpi_proxy.fpp[58-70]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Extrusion reads rank-00 only 🐞
Description
The extrusion reader hard-codes the middle filename field to .00. (prim..00..dat), so it cannot
read data produced with parallel I/O that is split across ranks (prim....dat). This can lead to
incomplete/incorrect extruded initial conditions or runtime failures when users follow the
documented prim.XX.YY.file_extension.dat naming.
Code

src/common/include/ExtrusionHardcodedIC.fpp[62]

+            fileNames(f) = trim(files_dir) // "/" // "prim." // trim(file_num_str) // ".00." // trim(file_extension) // ".dat"
Evidence
Docs describe an XX.YY filename format, and the codebase writes prim.*..* files (YY varies) in
pre_process output; however, the extrusion reader always uses YY="00", so it cannot consume
multi-rank outputs as-is.

src/common/include/ExtrusionHardcodedIC.fpp[59-67]
src/pre_process/m_data_output.fpp[162-166]
docs/documentation/case.md[259-267]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
IC extrusion currently assumes the source data files have processor-rank field `YY=00` in `prim.XX.YY.<ext>.dat`. This prevents extruding from source datasets produced with MPI/parallel I/O where data is split across multiple `YY` files.
### Issue Context
- The repository writes files as `prim.<var>.<proc_rank>.<t_step>.dat`.
- Documentation states the format is `prim.XX.YY.file_extension.dat` without stating `YY` must be `00`.
### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[59-67]
- src/pre_process/m_data_output.fpp[162-166]
- docs/documentation/case.md[259-267]
### Fix options (pick one)
1) **Implement support**: read and merge/sort data across all available `YY` partitions for each `XX` (most robust).
2) **Add a parameter**: e.g., `files_rank` (I2.2) and build filenames with that rank instead of hard-coding `00`.
3) **Clarify & enforce**: update docs to require `YY=00` / serial output, and add an explicit runtime check + clear abort message when expected files are missing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

6. case (271) wrong indentation 📘
Description
The newly added case (271)/case (272) blocks use 4+ space indentation instead of the required
2-space indentation, reducing consistency and readability. This violates the project Fortran style
rule for indentation on new/modified code.
Code

src/common/include/2dHardcodedIC.fpp[R275-331]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(momxb)%sf(i, j, 0) = q_prim_vf(momxb)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(momxe)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
+        @: HardcodedReadValues()
+
+        y_center = y0_ref
+        y_dist = y_cc(j) - y_center
+        wave_phase = 2.0_wp*pi*Nwaves*(y_dist/Ly_param)
+        front_shift = A_param*sin(wave_phase)
+
+        x_mapped = x_cc(i) - front_shift
+
+        if (x_mapped <= x_coords(1)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(1, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else if (x_mapped >= x_coords(xRows)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(xRows, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else
+            idx_lo = 1; idx_hi = xRows
+            do while (idx_hi - idx_lo > 1)
+                idx_mid = (idx_lo + idx_hi)/2
+                if (x_coords(idx_mid) <= x_mapped) then
+                    idx_lo = idx_mid
+                else
+                    idx_hi = idx_mid
+                end if
+            end do
+
+            interp_wt = (x_mapped - x_coords(idx_lo))/(x_coords(idx_hi) - x_coords(idx_lo))  ! weight in [0,1)
+
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = (1.0_wp - interp_wt)*stored_values(idx_lo, 1, &
+                          & v) + interp_wt*stored_values(idx_hi, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        end if
Evidence
PR Compliance ID 11 requires 2-space indentation for Fortran code. The newly added case (271) and
case (272) sections in src/common/include/2dHardcodedIC.fpp are indented with 4+ spaces
throughout the new lines (e.g., case line and nested if/do blocks).

CLAUDE.md
src/common/include/2dHardcodedIC.fpp[275-331]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Newly added Fortran code in `src/common/include/2dHardcodedIC.fpp` does not follow the required 2-space indentation style.

## Issue Context
Project style rules require 2-space indentation for Fortran sources; the new `case (271)` and `case (272)` blocks are indented with 4+ spaces.

## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


7. IC interpolation coords mismatch 🐞
Description
The new hcid=272 mapping uses x_mapped = x_cc(i) - front_shift but interpolates against x_coords
loaded from prim.* files whose x-coordinate column is written as x_cb. This inconsistent
coordinate basis shifts the reconstructed profile by roughly half a cell and can distort the
intended perturbed flame-front initialization.
Code

src/common/include/2dHardcodedIC.fpp[R301-325]

+        x_mapped = x_cc(i) - front_shift
+
+        if (x_mapped <= x_coords(1)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(1, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else if (x_mapped >= x_coords(xRows)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(xRows, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else
+            idx_lo = 1; idx_hi = xRows
+            do while (idx_hi - idx_lo > 1)
+                idx_mid = (idx_lo + idx_hi)/2
+                if (x_coords(idx_mid) <= x_mapped) then
+                    idx_lo = idx_mid
+                else
+                    idx_hi = idx_mid
+                end if
+            end do
+
+            interp_wt = (x_mapped - x_coords(idx_lo))/(x_coords(idx_hi) - x_coords(idx_lo))  ! weight in [0,1)
+
Evidence
HardcodedReadValues() populates x_coords from the first column of prim.* files; the simulation
writes that first column as x_cb(j) for primitive outputs. In hcid=272, the code
compares/interpolates this x_coords(·) against x_mapped derived from x_cc(i), but x_cc is
defined as the midpoint of adjacent x_cb values, so the two coordinate systems are offset by ~dx/2
on uniform grids.

/src/common/include/2dHardcodedIC.fpp[293-331]
/src/simulation/m_data_output.fpp[527-545]
/src/pre_process/m_start_up.fpp[171-185]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
In hcid=272 (premixed flame instability), `x_mapped` is computed from `x_cc(i)` but interpolation is performed over `x_coords` read from `prim.*` files, whose x-column is written as `x_cb`. This mixes cell-center and cell-boundary coordinates.

### Issue Context
- `x_coords` is populated by reading the first column of `prim.*`.
- Simulation output uses `x_cb(j)` for that first column.
- `x_cc` is defined as the midpoint of adjacent `x_cb` values.

### Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[293-331]

### Suggested fix options (pick one consistent approach)
1) Switch mapping to boundary coordinates:
  - Use `x_mapped = x_cb(i) - front_shift` (and ensure `x_cb` is in scope where this macro expands), then interpolate against `x_coords` directly.

2) Keep center-based mapping but shift to match file coordinates:
  - Compute `x_mapped_cb = (x_cc(i) + 0.5_wp*x_step) - front_shift` and use `x_mapped_cb` in the `x_coords` comparisons and interpolation weight.

3) Convert `x_coords` to a center coordinate array once:
  - Build `x_coords_cc(idx) = x_coords(idx) - 0.5_wp*x_step` (or another consistent transform based on how the files are generated) and interpolate using `x_coords_cc`.

Add a brief comment documenting the coordinate convention (prim files use `x_cb` in column 1).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


8. Non-2-space indentation added 📘
Description
The newly added case (271)/case (272) blocks use indentation that does not follow the required
2-space indentation style. This reduces consistency and violates the style compliance requirement.
Code

src/common/include/2dHardcodedIC.fpp[R275-331]

+    case (271)  ! Premixed Flame Vortices interctiom
+        @: HardcodedReadValues()
+        x1c = 0.0027_wp
+        y1c = 0.005_wp
+        x2c = 0.0027_wp
+        y2c = 0.003_wp
+        r1c = (x_cc(i) - x1c)**(2.0_wp) + (y_cc(j) - y1c)**(2.0_wp)
+        r2c = (x_cc(i) - x2c)**(2.0_wp) + (y_cc(j) - y2c)**(2.0_wp)
+        rvortex = 0.0005_wp
+        cvortex = 6000.0_wp
+
+        u1c = -cvortex*((y_cc(j) - y1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+        v1c = cvortex*((x_cc(i) - x1c))*exp(-r1c/(2.0_wp*rvortex**2.0_wp))
+
+        u2c = cvortex*((y_cc(j) - y2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        v2c = -cvortex*((x_cc(i) - x2c))*exp(-r2c/(2.0_wp*rvortex**2.0_wp))
+        q_prim_vf(momxb)%sf(i, j, 0) = q_prim_vf(momxb)%sf(i, j, 0) + u1c + u2c
+        q_prim_vf(momxe)%sf(i, j, 0) = v1c + v2c
+    case (272)  ! Prexmied flame instability
+        @: HardcodedReadValues()
+
+        y_center = y0_ref
+        y_dist = y_cc(j) - y_center
+        wave_phase = 2.0_wp*pi*Nwaves*(y_dist/Ly_param)
+        front_shift = A_param*sin(wave_phase)
+
+        x_mapped = x_cc(i) - front_shift
+
+        if (x_mapped <= x_coords(1)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(1, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else if (x_mapped >= x_coords(xRows)) then
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = stored_values(xRows, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        else
+            idx_lo = 1; idx_hi = xRows
+            do while (idx_hi - idx_lo > 1)
+                idx_mid = (idx_lo + idx_hi)/2
+                if (x_coords(idx_mid) <= x_mapped) then
+                    idx_lo = idx_mid
+                else
+                    idx_hi = idx_mid
+                end if
+            end do
+
+            interp_wt = (x_mapped - x_coords(idx_lo))/(x_coords(idx_hi) - x_coords(idx_lo))  ! weight in [0,1)
+
+            do v = 1, sys_size - 1
+                q_prim_vf(v + merge(1, 0, v >= momxe))%sf(i, j, 0) = (1.0_wp - interp_wt)*stored_values(idx_lo, 1, &
+                          & v) + interp_wt*stored_values(idx_hi, 1, v)
+            end do
+            q_prim_vf(momxe)%sf(i, j, 0) = 0.0_wp
+        end if
Evidence
PR Compliance ID 9 requires 2-space indentation in new or modified Fortran code. The added `case
(271)/case (272)` blocks are indented with more than 2 spaces throughout.

CLAUDE.md
src/common/include/2dHardcodedIC.fpp[275-331]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New code added under `case (271)` and `case (272)` does not follow the required 2-space indentation convention.
## Issue Context
This affects only the newly added blocks for premixed flame vortices/instability initialization.
## Fix Focus Areas
- src/common/include/2dHardcodedIC.fpp[275-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (1)
9. IC path truncation risk 🐞
Description
ExtrusionHardcodedIC stores full file paths into fileNames with character(len=150), while
path_len is 400 and files_dir alone can be 255 chars; long paths will be silently truncated and
then fail to open/read the IC files. This can break IC extrusion in deep directory layouts and is
hard to diagnose because truncation happens before the open() error check.
Code

src/common/include/ExtrusionHardcodedIC.fpp[45]

+    character(len=150), dimension(sys_size) :: fileNames                         !< Arrays to store all data from files
Evidence
The code constructs a full path into fileNames(f) but the buffer is only 150 characters, which is
smaller than the repo-wide max path length constant and smaller than the declared files_dir
buffer; Fortran will truncate on assignment, causing wrong paths passed to open().

src/common/include/ExtrusionHardcodedIC.fpp[38-63]
src/pre_process/m_global_parameters.fpp[20-25]
src/common/m_constants.fpp[10-22]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
IC extrusion builds file paths into `fileNames`, but `fileNames` is only `character(len=150)`. Since paths can be up to `path_len` (400) and `files_dir` is `character(len=255)`, the constructed path can be silently truncated before `open()`, leading to file-not-found at runtime.
### Issue Context
This PR already increases `fileNames` from 100 to 150, but 150 is still below `path_len` and can truncate valid paths.
### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[38-55]
- src/pre_process/m_global_parameters.fpp[20-26]
- src/common/m_constants.fpp[15-22]
### Expected change
- Change `fileNames` to `character(len=path_len)` (or larger if needed).
- Consider changing `files_dir` to `character(len=path_len)` for consistency.
- Keep MPI broadcasts using `len(files_dir)` / `len(file_extension)` so counts stay consistent with the declarations.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

10. Extrusion docs typos 🐞
Description
The updated documentation introduces a typo ("etup") and an inconsistent filename-token
(files_extension vs file_extension), which can mislead users configuring extrusion. This makes
the new workflow harder to follow and increases misconfiguration risk.
Code

docs/documentation/case.md[R265-266]

+etup: Only requires specifying `files_dir` and filename pattern via `file_extension`. The files are located, for example, at `examples/1D_flamelet/IC`, and their format is `prim.XX.YY.files_extension.dat`.
+Implementation: All variables and file handling are managed in the `case.py` file of the simulation.
Evidence
The docs now reference file_extension but also show a filename format containing
files_extension, and the "Setup" label is misspelled; meanwhile the toolchain/Fortran parameter is
file_extension (singular).

docs/documentation/case.md[262-267]
toolchain/mfc/params/definitions.py[1048-1051]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs for extrusion contain a typo and inconsistent parameter/token naming (`files_extension` vs `file_extension`).
## Issue Context
Users will likely copy/paste the documented pattern/parameter names into their cases.
## Fix Focus Areas
- docs/documentation/case.md[262-267]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


11. Stale extrusion header comment 🐞
Description
ExtrusionHardcodedIC.fpp’s header comment still claims filenames come from init_dir and
zeros_default, but the implementation now uses files_dir and file_extension. This
inconsistency can mislead maintainers/users when updating or debugging extrusion behavior.
Code

src/common/include/ExtrusionHardcodedIC.fpp[R51-54]

+    character(len=20)                       :: file_num_str                      !< For storing the file number as a string
+    character(len=20)                       :: zeros_part                        !< For the trailing zeros part
+    integer                                 :: ios = 0
+    integer                                 :: ios2 = 0
Evidence
The header documentation references init_dir/zeros_default even though those parameters were
removed and the code constructs names from files_dir/file_extension.

src/common/include/ExtrusionHardcodedIC.fpp[11-16]
src/common/include/ExtrusionHardcodedIC.fpp[34-36]
src/common/include/ExtrusionHardcodedIC.fpp[57-63]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The documentation block at the top of `ExtrusionHardcodedIC.fpp` still references removed parameters (`init_dir`, `zeros_default`) and no longer matches the current implementation.
### Issue Context
The implementation now builds filenames using `files_dir` and `file_extension`.
### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[11-36]
- src/common/include/ExtrusionHardcodedIC.fpp[57-63]
### Expected change
- Replace `init_dir` -> `files_dir` in the comment.
- Replace `zeros_default` / `<timestep>` wording -> `file_extension` wording.
- Ensure the documented filename pattern matches the actual constructed string (including the `.00.` field if it remains hard-coded).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines 98 to 102
! Calculate offsets
domain_xstart = x_coords(1)
x_step = x_cc(1) - x_cc(0)
delta_x = merge(x_cc(0) - domain_xstart + x_step/2.0, x_cc(index_x) - domain_xstart + x_step/2.0, num_dims == 1)
delta_x = merge(x_cc(0) - domain_xstart, x_cc(index_x) - domain_xstart + x_step/2.0, num_dims == 1)
global_offset_x = nint(abs(delta_x)/x_step)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. 1d extrusion index shift 🐞 Bug ≡ Correctness

HardcodedReadValues() now computes global_offset_x for 1D using x_cc(0) - x_coords(1) without
the half-cell correction, but x_coords comes from files written with x_cb coordinates. This
makes global_offset_x round to 1 instead of 0 (via nint), shifting all 1D extruded IC samples by
one index.
Agent Prompt
### Issue description
1D IC extrusion computes `global_offset_x` using `delta_x = x_cc(0) - x_coords(1)` (where `x_coords` is read from the first column of `prim.*.dat`). Because `prim.*` files write `x_cb(j)` as the coordinate while `x_cc` is cell-centered, this introduces a half-cell mismatch and `nint` rounds it to a full index shift.

### Issue Context
- `x_cc(0:m) = (x_cb(0:m) + x_cb(-1:(m-1)))/2` (cell centers)
- `prim.*` output uses `x_cb(j)` as the x-coordinate
- `HardcodedReadValues()` uses `global_offset_x = nint(abs(delta_x)/x_step)` and then indexes `stored_values` with `idx = i + 1 + global_offset_x`

### Fix Focus Areas
- src/common/include/ExtrusionHardcodedIC.fpp[98-103]

### Suggested fix
- For `num_dims == 1`, reintroduce the half-step correction when comparing `x_cc` to file coordinates, e.g.:
  - `delta_x = x_cc(0) - domain_xstart + x_step/2.0_wp`
- Add a short comment explaining that the first column in `prim.*` is `x_cb` while values are cell-centered.
- (Optional but ideal) add a small regression test covering hcid=170 on a uniform grid that verifies no one-cell shift occurs when extruding from a serial `prim.*` output.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant