vibeflow-openlb

name	vibeflow-openlb
description	Use when preparing, running, debugging, post-processing, or extending VibeFlow/VibeCAE OpenLB lattice-Boltzmann workflows from 0-caseDict/caseDict, including C++ applications, lattice units, geometry indicators, boundary conditions, parallel builds, VTK output, and reusable LBM templates.

VibeFlow OpenLB

This skill treats OpenLB as the VibeCAE lattice Boltzmann method backend for flow, heat transfer, multiphase work, porous media, particle coupling, and related LBM workflows.

• Usage mode: select or generate an OpenLB C++ application from caseDict, then compile, run, and post-process it.
• Development mode: develop OpenLB application templates, boundary/material adapters, geometry import, LBM parameter conversion, and Studio integration.

When to Use

• The user explicitly selects LBM/OpenLB, or the problem is suitable for the lattice Boltzmann method.
• Physical quantities must be converted to lattice units, relaxation time, lattice resolution, and time step.
• A C++ case needs to be derived from OpenLB examples.
• VTK, statistics, force coefficients, or probe curves are needed.

First Decide: Usage Mode or Development Mode

• Current-case OpenLB application configuration, build, and run: use usage mode.
• General C++ templates, geometry adapters, boundary wrappers, or parameter converters: use development mode.
• OpenLB source tree, compiler, MPI, or dependencies are unavailable: hand off to vibeflow-toolchain first.
• If the user needs conventional CFD results and does not care about LBM, compare OpenFOAM/SU2 first.

What to Read First

• Flow model, properties, geometry, boundaries, Re/Ma, target quantities, and output formats in 0-caseDict/caseDict.
• references/openlb-playbook.md
• references/openlb-practical-tips.md: software knowledge base, key concepts, failure interpretation, and adapter design notes.
• OpenLB source examples and current C-run/openlb/.
• Geometry and mesh artifacts, especially STL/indicator or voxelization requirements.

Input

• 0-caseDict/caseDict
• OpenLB source tree or current application template
• Geometry files, boundary definitions, property parameters, and resolution targets

Output

• C-run/openlb/case-*/src/*.cpp
• C-run/openlb/case-*/Makefile or build scripts
• C-run/openlb/case-*/Allrun / Allclean
• VTK, CSV, logs, and statistics
• D-post/openlb_postprocess.py

Recommended Structure

C-run/openlb/
`-- case-1/
    |-- src/
    |-- input/
    |-- build/
    |-- results/
    |-- logs/
    |-- Allrun
    `-- Allclean

Usage-Mode Workflow

1. Convert caseDict to LBM parameters: physical length, velocity, viscosity, Re, lattice resolution, time step, relaxation time, and Mach limit.
2. Select the closest template from OpenLB examples; do not start from an empty C++ file.
3. Write a case-specific C++ application with explicit geometry indicator, materials, boundary conditions, initialization, and output.
4. Compile the application and save the build log.
5. Run a short smoke test and check initialization, boundaries, VTK output, and statistics.
6. Run the formal case and post-process velocity, pressure, vorticity, forces, fluxes, or user target metrics.
7. Write parameter conversion, run status, and limitations back to caseDict.

Development-Mode Workflow

1. Define the development target: OpenLB case template, parameter converter, geometry importer, boundary wrapper, or output converter.
2. Write a development note first, recording the OpenLB version, source-tree location method, build method, template source, and validation case.
3. C++ templates must preserve the conversion from physical units to lattice units.
4. For new boundaries or geometry adapters, validate at least on a simple channel or cylinder benchmark.
5. Do not write a user-machine OpenLB installation path into the repository; use environment variables or configuration files.

Core Rules

• OpenLB is usually a source-level framework and may not provide a fixed system binary.
• caseDict stores the physical problem; the C++ application stores the execution implementation.
• LBM parameter conversion must check Mach number, relaxation time, and resolution.
• Geometry voxelization or indicator errors must be recorded.
• For parallel runs, output organization and partitioned results must be traceable.

Validation

• The OpenLB source root can be located.
• Compiler and MPI requirements are satisfied.
• The current application compiles.
• The smoke test generates VTK/CSV or log statistics.
• Key dimensionless numbers and lattice parameters are in a reasonable range.

Fallback Rules

• Physical quantities or target Re/Ma are unclear: return to vibeflow-case-dict.
• OpenLB source or build environment is unavailable: return to vibeflow-toolchain.
• Geometry indicator fails: return to geometry or mesh.
• LBM is unsuitable for the operating condition: recommend switching to OpenFOAM, SU2, Elmer, or another backend.