vibeflow-postprocess

name	vibeflow-postprocess
description	Use when planning, extracting, validating, plotting, visualizing, or summarizing VibeFlow OpenFOAM results from C-run and 0-caseDict/caseDict, including postProcessing data, probes, forces, forceCoeffs, samples, field files, solver logs, Python metrics, ParaView/pvpython scenes, evidence tables, figures, animations, and report-ready artifacts.

VibeFlow Postprocess

This skill turns solver results into evidence that can answer the user's question. Post-processing is not about piling up figures; it extracts metrics, field images, tables, and traceable conclusions around intent.targetOutputs and postProcessing.objectives.

When to Use

• Metrics such as pressure drop, drag, flow rate, temperature, and phase fraction need to be extracted.
• Line plots, time histories, or parameter comparisons need to be drawn.
• Visualizations such as slices, isosurfaces, streamlines, vector fields, and particle trajectories are needed.
• A decision is needed on whether a post-processing objective should use Python or ParaView.
• Solver logs, postProcessing/, time directories, or sampled data need to be inspected to decide whether the computation sufficiently supports the conclusion.
• Report-ready csv files, images, animations, scenes, and summaries under D-post/ need to be prepared.

What to Read First

• caseMeta, intent, physicalProblem, materials, regions, interfaces, execution, postProcessing, report, and errors in 0-caseDict/caseDict.
• Logs, time directories, postProcessing/, and system function objects under C-run/.
• Data sources, chart strategy, and Python/ParaView division of work: references/postprocess-playbook.md.

Input

• 0-caseDict/caseDict
• Results under C-run/
• B-mesh/ or C-run/constant/polyMesh when mesh-quality views are needed
• Existing scripts or charts under D-post/

Output

• D-post/postprocess.py, D-post/pvpython.py, D-post/scenes.py, csv files, images, animations, ParaView state/scene files, and D-post/summary.md.
• Updates to postProcessing, report.sections, execution.artifacts, and errors when required.

Recommended Workflow

1. Read postProcessing.objectives.primaryMetrics and clarify what question each figure or table answers.
2. Check whether the run is sufficient: final time, logs, residuals, physical monitored quantities, and unresolved errors.
3. List data sources: function objects, samples, probes, forces, time-directory field files, and solver logs.
4. Produce numerical summaries and quality judgments first, then line plots/tables, and finally scene visualizations.
5. Use Python for tables, curves, and statistics; use ParaView/pvpython for slices, isosurfaces, streamlines, vectors, and mesh scenes.
6. Write output paths to postProcessing.artifacts, and provide key figures for the report.
7. If results are insufficient to support the conclusion, write to errors or return to vibeflow-openfoam.

ParaView GUI Python Control

When the user asks to operate the ParaView GUI in the current Studio Workspace, such as importing case.foam, adding slice/contour/clip filters, switching the coloring variable, adjusting the camera, saving screenshots, or saving state, preferentially generate a paraview.simple script instead of only describing manual click steps.

• Use from paraview.simple import * as the script entry.
• If the goal is to control the current Studio GUI, the script should target the current ParaView session: use GetActiveViewOrCreate("RenderView"), GetActiveSource(), SetActiveSource(...), Show(...), and Render().
• If the goal is offline batch processing or file generation and the current GUI does not need to be changed, use /usr/bin/pvpython to execute a similar script.
• File paths must use absolute paths or stable paths resolved from the current case root. Prefer opening OpenFOAM results through C-run/case.foam.
• Common OpenFOAM reader settings include MeshRegions, CellArrays, PointArrays, and SkipZeroTime; select only regions and fields needed for the post-processing objective.
• After GUI operations, call UpdatePipeline() or Render(). Use SaveScreenshot(...) when screenshots are needed, and SaveState(...) when reproducible GUI state is needed.
• Do not set view.ViewSize when D-post/scenes.py controls the current Studio GUI; Studio automatically synchronizes the GUI viewport size. ViewSize is only used in D-post/pvpython.py for offline screenshots or SaveScreenshot resolution control.
• When controlling the current Studio GUI, write incremental scripts: first look for and reuse existing objects, and create only missing objects; do not rebuild the entire scene by default.
• Objects created or maintained by AI must be named VF_*; scripts should only modify VF_* objects, protecting by default any objects manually created or adjusted by the user in the GUI.
• Do not call ResetSession(), batch Delete(...), or clear the Pipeline by default; these are allowed only when the user explicitly requests a reset.
• Do not hard-code complex visualization requirements into a small fixed set of commands; generate ParaView Python scripts that are readable, reproducible, and reviewable.
• Studio GUI interaction scripts are always saved to D-post/scenes.py; Studio listens for changes to this file and automatically executes it in the current GUI session, so do not manually run it again.
• Offline ParaView batch scripts are always saved to D-post/pvpython.py; ordinary data post-processing scripts are always saved to D-post/postprocess.py.
• Save screenshots to D-post/figures/, data to D-post/data/, animations to D-post/animations/, and inspect the execution log at D-post/logs/paraview_executor.log.

Minimal example:

from paraview.simple import *

case = OpenFOAMReader(FileName="/path/to/C-run/case.foam")
case.MeshRegions = ["internalMesh"]
case.CellArrays = ["U", "p"]

view = GetActiveViewOrCreate("RenderView")
Show(case, view)
ColorBy(GetDisplayProperties(case, view), ("POINTS", "U", "Magnitude"))
RescaleTransferFunctionToDataRange()
ResetCamera()

slice1 = Slice(Input=case)
slice1.SliceType.Origin = [0.5, 0.0, 0.0]
slice1.SliceType.Normal = [1.0, 0.0, 0.0]
Show(slice1, view)
Render()

Rules

• Post-processing objectives must map back to intent.targetOutputs and caseDict.postProcessing.objectives.
• Keep only figures and tables that answer the question or validate quality.
• Key figures must have physical meaning, units, coordinate directions, and field descriptions.
• Derived-quantity formulas, reference quantities, and sampling windows must be traceable.
• Do not package unconverged, unverified, or smoke-test-only results as final conclusions.
• Use stable chart names, such as D-post/figures/force_coeffs.png and D-post/data/pressure_drop.csv.
• When results are missing, scripts fail, or data are inconsistent, write to errors.entries with stage=post.

Validation

• Key metrics have been extracted.
• Key charts have been generated.
• Output paths are stable.
• Conclusions are traceable to raw data.
• postProcessing.artifacts matches actual files.
• Evidence required by the report has been covered, or gaps have been clearly recorded.

Fallback Conditions

• OpenFOAM results are missing, diverged, too short in time, or function objects were not generated: return to vibeflow-openfoam.
• pvpython, Python packages, or reader tools are unavailable: return to vibeflow-toolchain.
• Post-processing objectives are unclear, or metric definitions affect physical conclusions: return to vibeflow-case-dict.
• Evidence is complete and reporting objectives are clear: hand off to vibeflow-report.