Tutorial: Using a File-Based Grid (Bent Channel)

Table of Contents

• 1. Initialize a Study
• 2. File-Grid Configuration
• 3. Run the Case
• 4. Visualize Results
• 5. Next Steps
  • CFD Reader Guidance and Practical Use
    • What To Extract Before Changing A Case
    • Practical CFD Troubleshooting Pattern

This tutorial demonstrates grid.mode: file using the bent_channel template.

1. Initialize a Study

./bin/picurv init bent_channel --dest my_bent_channel_run

Expected files:

my_bent_channel_run/
|- bent_channel.yml
|- Imp-MG-Standard.yml
|- Standard_Output.yml
|- standard_analysis.yml
|- bent_channel_coarse.picgrid
|- bent_channel_coarse.vts
`- bent_channel_coarse.info

2. File-Grid Configuration

In bent_channel.yml:

grid:
  mode: file
  source_file: bent_channel_coarse.picgrid

Behavior:

• picurv validates the source grid file exists.
• Coordinates are non-dimensionalized before C execution using properties.scaling.length_ref.
• Generated normalized grid is staged into run config artifacts.

3. Run the Case

./bin/picurv run \
    --case my_bent_channel_run/bent_channel.yml \
    --solver my_bent_channel_run/Imp-MG-Standard.yml \
    --monitor my_bent_channel_run/Standard_Output.yml \
    --post my_bent_channel_run/standard_analysis.yml \
    -n 4 --solve --post-process

4. Visualize Results

1. Open runs/<run_id>/viz/Field_*.vts.
2. Use Stream Tracer seeded near inlet.
3. Color by Ucat_nodal magnitude.

This provides a fast sanity check of bend-flow behavior.

5. Next Steps

Proceed to Tutorial: A Guide to Visualizing Your Results.

CFD Reader Guidance and Practical Use

This page describes Tutorial: Using a File-Based Grid (Bent Channel) within the PICurv workflow. For CFD users, the most reliable reading strategy is to map the page content to a concrete run decision: what is configured, what runtime stage it influences, and which diagnostics should confirm expected behavior.

Treat this page as both a conceptual reference and a runbook. If you are debugging, pair the method/procedure described here with monitor output, generated runtime artifacts under runs/<run_id>/config, and the associated solver/post logs so numerical intent and implementation behavior stay aligned.

What To Extract Before Changing A Case

• Identify which YAML role or runtime stage this page governs.
• List the primary control knobs (tolerances, cadence, paths, selectors, or mode flags).
• Record expected success indicators (convergence trend, artifact presence, or stable derived metrics).
• Record failure signals that require rollback or parameter isolation.

Practical CFD Troubleshooting Pattern

1. Reproduce the issue on a tiny case or narrow timestep window.
2. Change one control at a time and keep all other roles/configs fixed.
3. Validate generated artifacts and logs after each change before scaling up.
4. If behavior remains inconsistent, compare against a known-good baseline example and re-check grid/BC consistency.